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Preface 



This publication provides an overview of Advanced Communications Function 
for the Telecommunications Access Method (ACF/TCAM), Version 2, 
Releases 1, 2, and 3. The ACF/TCAM program product supports IBM's 
Systems Network Architecture (SNA) and operates with OS/VS1 and OS/VS2 
MVS. The manual describes ACF/TCAM's operation with NCP/VS, Version 
5, or ACF/NCP/VS, Releases 1, 2, or 3 executing in an IBM 3705 
Communications Controller; the generic term network control program is to 
refer to either of these programs. 

The manual is directed primarily to data processing managers, their technical 
staff, and others who desire information that will enable them to evaluate 
Version 2 of the ACF/TCAM program product. The reader of this manual 
should be familiar with the basic concepts of data communication. 

This manual is divided into four chapters and a glossary. 

"Chapter 1. An Overview of ACF/TCAM, Version 2" is a high-level 
description of the entire ACF/TCAM program product; new functions for 
Version 2 are not singled out in this chapter. 

"Chapter 2. Summary of New Capabilities in ACF/TCAM, Version 2, 
Releases 1 and 2" describes each new function for Release 1 and Release 2 of 
ACF/TCAM, Version 2. 

"Chapter 3. Summary of New Capabilities in ACF/TCAM, Version 2, 
Release 3" describes each new function for Release 3 of ACF/TCAM, Version 
2. 

"Chapter 4. Migration and Planning Considerations" tells which network 
control programs will operate with each new ACF/TCAM function, and the 
devices and subsystems that can be used with Version 2 of ACF/TCAM. 

The "Glossary of Terms and Abbreviations" contains terms and abbreviations 
used in the manual that may be unfamiliar to the reader. 



Related Reading 



ACF/NCP/VS (Network Control Program and System Support Programs) 
General Information, GC30-3058. The shortened title as used in text is 
ACF/NCP-SSP General Information. 



Introduction to Advanced Communications Function, GC30-3033. 

Introduction to the IBM 3 704 and 3 705 Communications Controllers, 
GA27-3051. This manual contains information about NCP/VS, Version 5, and 
ACF/NCP/VS, Release 1, only. 

Network Communication Control Facility General Information, GC27-0429. 

Network Problem Determination Application General Information, 
GC34-2010. 



Programmed Cryptographic Facility General Information, GC28-0942. 
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Chapter 1. An Overview of ACF/TCAM, Version 2 



IBM's Advanced Communications Function for the Telecommunications 
Access Method (ACF/TCAM) is a program product that resides in a host 
processor and directs traffic in a network. ACF/TCAM operates under 
control of either OS/VS1 or OS/VS2 MVS. ACF/TCAM conforms to IBM's 
Systems Network Architecture (SNA) while also allowing stations attached to 
binary synchronous and start-stop lines to be used in the network. This manual 
describes ACF/TCAM, Version 2, Releases 1, 2, and 3. The term 
ACF/TCAM is used throughout the remainder of the manual to mean 
ACF/TCAM, Version 2. 

Note: The term network has at least two meanings. A public network is a network 
established and operated by common carriers or telecommunication Administrations for 
the specific purpose of providing circuit-switched, packet-switched, and leased-circuit 
services to the public. A user application network is a configuration of data processing 
products, such as processors, controllers, and terminals, established and operated by users 
for the purpose of data processing or information exchange, which may use transport 
services offered by common carriers or telecommunication Administrations. Network, as 
used in this publication, refers to a user application network. 

ACF/TCAM controls the network from a host processor. As shown in Figure 
1-1, an IBM 3705 Communications Controller can be either local to its host 
processor — that is, physically attached to one or more host-processor data 
channels; or it can be remote — that is, at a distance from the host processor 
that precludes its being attached to a data channel 1 . A remote controller is 
connected to a local controller by an SDLC data link. (Local controllers are 
also called channel-attached controllers and remote controllers are also called 
link-attached controllers.) Figure 1-1 shows that some stations can also be 
attached to a host-processor data channel; these are called local stations. As 
used throughout this publication, the term data link, or simply link, refers to the 
communication facility over which information is transmitted between a remote 
device (station or communications controller) and a local communications 
controller. 

The line discipline for the communication between communications controllers 
is synchronous data link control (SDLC); the line discipline between a 
communications controller and a station can be binary synchronous (BSC), 
start-stop (SS), or SDLC. In Chapter 4, Figure 4-1 lists all of the stations that 
can coexist in a network with ACF/TCAM, their attachment (local or remote), 
and their line disciplines. 

The basic unit of data that ACF/TCAM transmits throughout the network is 
called a message. ACF/TCAM manages the flow of messages between: 

• Itself and application programs 

• The host processor and communications controllers 

• The host processor and remote stations 

• The host processor and local stations 



^CF/TCAM can also operate with an IBM 2701 Data Adapter Unit or an IBM 2702 or 
2703 Transmission Control. ACF/TCAM's operation with these control units is not 
described in this publication. 
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• The host processor Wj& is the processing unit with an operating system, an access method, and application programs; it oversees the 
entire network. 

• The communications controller ^3 manages the details of line cont rol a nd routing of data through the network. It can route data 
to the host processor, to or from another communications controller Cu , or from a remote station. 

• Stations^J^ provide attachment for one or more input/output devices. Unless a distinction is required, the term station is used throughout 
this publication to mean both an SDLC station and a BSC/SS station. 

• At the ends of the network are end users. These may be people (such as terminal operators), application programs, or input/output devices 
(such as card readers or printers). They represent the origin or destination of much of the information that is routed throughout the 
network. End users themselves are not identified to the network; they gain access to network resources through logical units, which have 
unique network names. 

• Logical units are an end user's access to the services of the network and may be part of either a program or a hardware component. 
Figure 1-1. Resources in an ACF/TCAM Network 
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The Message Control Program 

The job-step task for ACF/TCAM is the ACF/TCAM initiator program, 
which monitors the ACF/TCAM region. The initiator should have the highest 
priority in the operating system; it, in turn, attaches subtasks that perform 
ACF/TCAM functions 2 . The initiator's most important subtask is the message 
control program. The system programmer codes ACF/TCAM macro 
instructions to define the functions that he wants ACF/TCAM to perform. 
These macros generate tables, lists of control information defining the 
ACF/TCAM environment, and message-handler routines (referred to as 
message handlers) . Message control program (MCP) is a generic term for the 
code generated by these ACF/TCAM macros. The coding requirements and 
restrictions for ACF/TCAM macros are the same as those for other 
assembler-language macro instructions. 

Some customers whose message handlers require little or no customization can 
use (with modification, if desired) an IBM-supplied model message control 
program. Other customers — particularly those with complex networks — may 
choose to incorporate their own assembler-language code into the message 
handlers, customizing them for precisely the functions needed. In addition to 
the model MCP, IBM also supplies a TSO MCP and TSO message handler. 

ACF/TCAM Application Programs 

The term ACF/TCAM application program or simply application program, as 
used here and throughout this manual, refers to customer-written application 
programs that interface with the MCP using ACF/TCAM's basic 
(READ /WRITE/ CHECK) or queued (GET/PUT) data-transfer macros. 
ACF/TCAM application programs may process messages entered from 
stations, and may themselves enter messages to be sent to other stations and 
application programs. The interface between an ACF/TCAM application 
program and the MCP is called the GET /PUT application program interface 
(API). (Use of the term GET/PUT API implies that either GET/PUT macros 
or READ/ WRITE/ CHECK macros can be used.) In addition to the 
GET/PUT API for customer-written application programs, ACF/TCAM 
provides a compatibj^ubset^of jthe ACF/VTAM record API for certain 
IBM-supplied subsystems that were written to run with ACF/VTAM. These 
subsystems are listed in Chapter 2 under the topic "ACF/TCAM's Subsystem 
Support." Differences in ACF/TCAM's operation with subsystems are pointed 
out under this topic and where applicable throughout the manual. 

Application programs operate asynchronously with ACF/TCAM. 
ACF/TCAM application programs are independent of line activities (such as 
line scheduling) and attachment concerns (such as whether a station is local or 
remote). Since ACF/TCAM application programs are insulated from most 
ACF/TCAM operations, application programs used with other versions of 
TCAM will execute with ACF/TCAM. 

An ACF/TCAM application program views the network as a sequential flow 
of data accessed in much the same way as a tape drive would be accessed. 
Because of this, the application programmer can test the logic of an application 



2 The other subtasks that the ACF/TCAM initiator attaches are system service programs; 
they are discussed in Chapter 2 under the topic, "Installability and Usability 
Enhancements." 



ACF/TCAM Version 2 General Information: Introduction 1-3 



Message Queuing 3 



program before it is actually used for message processing. For example, input 
"messages" can come from a tape drive or card reader with output going to a 
printer. 

ACF/TCAM application programs can issue operator commands and macro 
instructions to monitor and change the status of a network. This capability 
allows an installation to use a programmed operator for network control. 
Network-control procedures can be a combination of operator actions and 
application-program execution. For example, instead of typing a long series of 
ACF/TCAM operator commands, an operator could type an 
installation-defined command that would cause the appropriate sequence of 
ACF/TCAM operator commands to be issued from an application program. 
Additionally, if an installation wished to keep a log of all or some of its 
network activities, an application program could keep such a log. The topic 
"Network Communication," later in this chapter also discusses the use of 
operator commands and network-control macros from an application program. 



ACF/TCAM is a queued access method; that is, ACF/TCAM is designed to 
handle messages arriving at an unpredictable rate. ACF/TCAM maintains 
message queues that hold messages until they can be sent to their destinations. 
A message entering ACF/TCAM can be queued on direct-access storage 
devices, in main storage, or both. 

When messages are queued on direct-access storage devices, ACF/TCAM can 
provide: 

• Message retrieval 

• Message rerouting 

• Sending to multiple destinations (broadcasting) 

• Interception of messages destined for inactive stations 

• Checkpoint/restart capability 

Queuing messages in main storage is faster than queuing them on direct-access 
storage devices. However, main-storage queuing without backup queuing on 
secondary storage has these disadvantages: 

• It ties up main storage that could be used otherwise 

• It restricts message retrieval capabilities 

• It does not allow checkpoint/restart, message rerouting, or message 
interception 

Main-storage queuing with backup queues on secondary storage uses more 
main storage than queuing on secondary storage alone; it may also results in 
longer response times than queuing in main storage alone. Yet, this queuing 
method combines many attractive features of each individual method. For 
many applications, this is an acceptable compromise between the speed of 
main -storage-only queuing and the reliability of queuing on direct-access 
storage devices. 



3 ACF/TCAM performs no message queuing when a customer accesses the services of the 
subsystems mentioned in Chapter 2 under "ACF/TCAM's Subsystem Support." 
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Resource Sharing 

ACF/TCAM allows resources to be shared among users of the network. A 
customer can define the network so that any ACF/TCAM application program 
can communicate with stations or other application programs without regard 
for their physical locations. Resources that make up the paths between 
application programs and remote stations are also shared. ACF/TCAM uses 
these resources (such as communications controllers and data links) on behalf 
of application programs and stations only as long as needed to complete a 
specific data transfer request. 

In an SNA-based network controlled by ACF/TCAM, a terminal operator 
gains access to the services of the network through an ACF/TCAM device 
message handler 4 . Device message handlers route messages to and from 
devices in the network. (Application message handlers, route messages to and 
from application programs.) That is, the terminal operator in an SNA session is 
connected (by a logon operation) to a device message handler. This device 
message handler is now in a position to analyze each message (or transaction) 
from the station. The system programmer can code a device message handler 
so that it resolves any dependencies of stations before messages are routed to 
an application program. When message handlers are used in this way: 

• Application programmers do not have to understand device dependencies 

• Device dependencies are not duplicated in each application program 

• New types of stations can be supported without impacting application 
programs 

One level of network sharing is the capability of a station to direct messages to 
multiple application programs, stations, or both through one message handler 
With SNA, terminal operators have a second layer of network sharing — the 
capability of selecting the device message handler that will be used during an 
SNA session. The different device message handlers might provide specific 
functions related to a particular application or be generalized to handle mixed 
input for many applications. In the latter case, a terminal operator who is in an 
SNA session with an ACF/TCAM device message handler can switch between 
applications without having to end the current SNA session and start another. 

Communications Controllers 

ACF/TCAM uses the IBM 3705-1 and 3705-11 Communications Controllers to 
communicate with the network; these controllers manage the flow of data 
between ACF/TCAM and remote stations. Communications controllers use 
SDLC data links to communicate with each other 5 . 



4 There are differences in the use of message handlers when messages are flowing to or from 
a subsystem. The topic "ACF/TCAM's Subsystem Support" in Chapter 2 discusses these 
differences. 



5 Multiple links between two network control programs (NCPs) can operate simultaneously 
only if the NCPs are Release 3 of ACF/NCP/VS. Also with Release 3 of ACF/NCP/VS, a 
single remote controller can be connected to multiple local controllers, and remote 
controllers can be connected to each other. Refer to Chapter 3 for additional information. 
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The communications controller is programmable and is controlled by either an 
IBM network control program (NCP) or the emulation program (EP) 6 . 
The generic term network control program, or simply NCP, is used in this 
manual when referring to either the IBM Network Control Program/Virtual 
Storage (NCP/VS), Version 5, or to the IBM Advanced Communications 
Function for the Network Control Program/Virtual Storage (ACF/NCP/VS), 
Releases 1, 2, and 3. NCP/VS, Version 5, can be used for single-domain 
communication, while ACF/NCP/VS can be used for both single-domain and 
multiple-domain communication. (Domains are discussed under the next topic 
"Network Characteristics".) Refer to "Network Control Programs Required 
for Specific New ACF/TCAM Functions" in Chapter 4 for additional 
information. The publications, ACF/NCP-SSP General Information, 
GC30-3058 (for ACF/NCP/VS), and Introduction to the IBM 3704 and 
3705 Communications Controllers, GA27-3051 (for NCP/VS, Version 5), 
have more information about network control programs and the emulation 
program. 

The network control program fulfills the concept of distributed function in 
SNA-based networks by performing many communication-control functions 
that ACF/TCAM would otherwise have to perform. General descriptions of 
networks in this publication refer to ACF/TCAM's operation with 
communications controllers loaded with the network control program. With 
the network control program, the communications controller performs 
network-control functions and operates its attached lines in network control 
mode. 

The network control program can be generated with the partitioned emulation 
programming (PEP) extension the extension allows a communications 
controller to operate some lines in emulation mode while concurrently 
operating other lines in network control mode. The PEP extension allows 
flexibility for the customer who is migrating from a network controlled by 
TCAM and the emulation program (EP). 

Network Characteristics 

A domain is the collection of network resources controlled by a system services 
control point (SSCP) 7 . A single-domain network has one SSCP controlling one 
domain; a multiple-domain network has more than one SSCP, each controlling 
its own domain. The resources controlled by an SSCP include application 
programs, subsystems, communications controllers, network control programs, 
stations, data links, and data channels. Figure 1-1 is an example of a 
single-domain network; Figure 1-2 is an example of of a multiple-domain 
network. 

Single-domain networks can operate with multiple concurrent application 
programs and both SNA and non-SNA stations with extensive sharing of 
network resources. Yet, while two or more single-domain networks may 



6 The emulation program allows a local 3705 to emulate the operation of an IBM 2701, 
2702, or 2703 of any combination of the three. A communications controller loaded with 
the emulation program operates its attached lines in emulation mode 



7 The functions of an SSCP are defined by systems network architecture (SNA). 
ACF/TCAM and ACF/VTAM each have SSCPs; further discussion of SSCPs is beyond 
the scope of this manual. Refer to Introduction to Advanced Communications Function, 
GC30-303 3, for additional information. 
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Figure 1-2. An Example of a Multiple-Domain Network 
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coexist — even sharing the same host processor and the same communications 
controller — the networks remain independent of each other; they lack the 
capability of communicating with each other. 

With ACF/TCAM's Multisystem Networking Facility (an optional feature), 
two or more interconnected domains can be consolidated into a 
multiple-domain network. The concept of communication between resources 
in different domains is called networking. With networking, an application 
program or subsystem in one domain can exchange data with an application 
program, subsystem, or station in another domain. The advantages of 
networking include: 

• Extended sharing of resources across domains 

• Elimination of redundant applications programs in two or more domains 

• Possible decrease in cost by utilizing cross-domain resources 

• Concurrent transmission of data over multiple routes between 
ACF/NCP/VSs 8 

• Backup capability for critical applications or stations, including the 
capability of using alternate routes for failed links or ACF/NCP/VSs 

IBM 3705 Communications Controllers containing ACF/NCP/VS are used to 
interconnect domains. This interconnection can be (1) by one or more SDLC 
data links between controllers or (2) by using the shared-ACF/NCP/VS 
capability of a single communications controller. Both of these methods of 
interconnection are shown in Figure 1-2. The publication, ACF/NCP-SSP 
General Information, GC30-3058, and Introduction to Advanced 
Communications Function, GC30-3033, have more information about 
ACF/NCP/VS's sharing capability. 



Network Security 



Most installations have security procedures for those who access the services of 
the network. ACF/TCAM provides the following measures that an installation 
can incorporate into its network security plan: 

• Passwords to be used by application programs when issuing network-control 
macros 

• Verification of an application's authority to access a destination queue 

• The security and authorization service facility (See "Installability and 
Usability Enhancements" in Chapter 2.) 

• Message logging 

• Exit routines that can be used when SNA sessions between logical units are 
established and terminated 



Additionally, IBM's Programmed Cryptographic Facility can be used with 
ACF/TCAM. With this program product, data transmitted during an SNA 
session can be enciphered and deciphered. More information about the 
cryptographic facility is in the publication, Programmed Cryptographic Facility 
General Information, GC28-0942. 



Network Management 



After ACF/TCAM has been defined, operator commands and certain 
application-program macros are used to manage the network. 



8 Multiple routes can be used with Release 3 only. See "Multiple Routing" in Chapter 3 for 
additional information. 



(Application-program macros are briefly discussed later under this topic.) 
ACF/TCAM operator commands can be issued by a human operator, an 
application program, or a combination of both, thus allowing an installation 
flexibility in planning its network-control procedures. 

Two operator control system service programs are subtasks of ACF/TCAM's 
initiator program: basic operator control (required) and extended operator 
control (optional). Both basic and extended operator commands can be 
entered from the system console, a terminal, or an application program. Once 
ACF/TCAM is active, basic operator commands can be used to: 

Monitor the network and its resources 
Change the network configuration 
Request services such as traces and dumps 
Establish connectivity to a network control program 
Start and stop message traffic to a destination 
Start and stop a network control program 
Stop ACF/TCAM 

Operator commands are the vehicle for network tuning, network 
reconfiguration, and problem determination. The network operator issues 
Display commands to request network status information. The information 
displayed enables the operator to determine what other operator commands are 
required either to remedy the situation or to request additional information, 
such as a trace. 

Extended operator control allows commands to be issued that are not required 
to control the domain; these commands can be used to perform operations such 
as displaying information about stations, queues, and ACF/TCAM buffer 
units. The extended operator control system service program is required in 
order to use: 

• ACF/TCAM's extended networking capability 

• The online retrieval system service program 

• The save/restore message queues system service program 

• The automatic purge/copy /redirect facility 

Refer to "Installability and Usability Enhancements" in Chapter 2 for 
additional information on extended operator control and the items listed above. 

In multiple-domain networks, operator commands can be used to request 
information about cross-domain resources. Depending upon the configuration 
and user-provided authorization, the operator in one domain may have access 
to the operator control facility in another domain. In this case, that operator 
can send cross-domain operator commands to the operator control facility of 
the ACF/TCAM message control program controlling the other domain. This 
capability allows the operator to inspect and manage resources belonging to the 
other domain. 

Application programs can issue network-control macros as well as operator 
commands. These macros allow the program to. 

• Examine and change the contents of certain ACF/TCAM control blocks 

• Resume sending messages to a destination that has not been allowed to 
receive messages 

• Stop ACF/TCAM 
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Problem Determination 



An installation can prohibit unauthorized use of these macros by requiring that 
a security password be coded with the macros in an application program. 



In some cases, the Display commands or an error message can point to the 
problem in a network. However, problem determination is complex for large 
networks, and additional means of problem determination are required. 
Isolation of a problem in large networks is made even more difficult since a 
problem at one point in the network may manifest itself in many other places. 
Therefore, in addition to operator commands and error messages, ACF/TCAM 
has the following facilities that can be used to gather information for problem 
determination: 

• Message logging 

• Error recording 

• Hardware tests 

• Dumps and traces 

Additionally, the Network Communications Control Facility and the Network 
Problem Determination Application program products can operate with 
ACF/TCAM. These program products can be used to isolate network 
problems. Refer to the following publications for more information: Network 
Communication Control Facility General Information, GC27-0429, and 
Network Problem Determination Application General Information, 
GC34-2010. 

Message Logging: ACF/TCAM's message logging facility enables an 
installation to record the messages handled by a particular message control 
program; this record is kept on a sequential data set. Message logging can be 
used by an installation for accounting purposes without requiring that a 
message-logging application program be written. Additionally, message 
logging can be a useful debugging tool. Inclusion of a carefully designed 
message-logging facility in a message handler permits a trace of the flow of 
messages through a message control program, thus allowing quick diagnosis of 
errors while debugging the message control program. By anticipating the need 
for debugging aids when designing a message-logging facility, an installation 
can provide a useful diagnostic tool with very little programming effort. 
Because of its modular design, the message-logging facility can be easily 
removed after the message control program has been debugged without 
requiring that portions of the message control program be rewritten. 

Error Recording: The error-recording facility helps to reduce the time that 
network components are inoperative by providing information useful in 
diagnosing data-link and station problems. ACF/TCAM creates error records 
for resources attached to communications controllers. These records contain 
statistical data about errors detected by the network control program. 
ACF/TCAM also internally maintains this error information for individual 
links and stations; the network operator can issue an operator command that 
will display error statistics. Additional related information about error 
recording is in Chapter 2 under the topic, "Intensive Mode Error Recording." 

Hardware Tests: An SNA-terminal operator can run a test to verify that his 
station can communicate with its host processor. The terminal operator sends a 
test request to the host. If the test was successful, the host replies with either 
the test message sent by the terminal operator or with the default test message. 
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In a similar type of test, the network operator can verify that communication is 
established between a remote SNA station (cluster node or terminal node) and 
its host processor. The operator begins the test by issuing an operator 
command from the operator control station; the results of the test are sent to 
the operator control station. Communication between the host processor and 
other stations on the nonswitched data link are not disrupted. 

ACF/TCAM provides the teleprocessing online test executive (TOTE) as 
another means of diagnosing network problems. TOTE allows online 
diagnostic tests to be performed for various stations in the network. The 
devices that can be used with TOTE are listed in Chapter 4. 

Dumps and Traces: Dumps and traces supply detailed information that can be 
used in determining the cause of a problem. The ACF/TCAM ABEND dump 
records the status of the message control program at the time that it failed. In 
the dump, all of the basic ACF/TCAM control blocks are formatted, and the 
customer can optionally print several other control blocks. The ACF/TCAM 
dump is in addition to the operating-system ABEND dump. 

ACF/TCAM also provides a number of optional traces for diagnosing 
problems. A trace program records its information while ACF/TCAM is in 
operation, thus permitting the customer to see certain control areas as they 
change. The ACF/TCAM customer may choose to have trace information 
recorded in a COMWRITE data set and later use the COMEDIT utility to 
format and print the data set. 

Release 3 of ACF/TCAM has additional problem-determination facilities; 
refer to "Network Problem Determination" in Chapter 3 for additional 
information. 

Recovering from Problems in the Network 

This topic discusses four levels of recovery in ACF/TCAM-controlled 
networks: ACF/TCAM's disk error-handling facility; 
communications-controller error-recovery procedures, ACF/TCAM's 
checkpoint/restart facility; and network recovery. 

ACF/TCAM's Disk-Error-Handling Facility: When a disk input/output error 
occurs during an attempt to read from or write on a disk, ACF/TCAM detects 
the error and gathers descriptive information about the error. Whenever a disk 
input/output error interrupt occurs, ACF/TCAM examines the appropriate 
bits and takes action accordingly. If intervention is required, control is 
returned to the operating system. When an irrecoverable error occurs, the 
operating system issues an abnormal termination message. 

Communications-Controller Error-Recovery Procedures: The network control 
program performs most device error-recovery procedures for remote devices in 
the network. The network control program will attempt recovery from most 
device-oriented errors; ACF/TCAM's error-recovery routines are used only 
for errors occurring when data is transmitted between the host and the 
communications controller. 

ACF/TCAM's Checkpoint/Restart Facility: ACF/TCAM's 

checkpoint/restart facility allows ACF/TCAM to be restarted with minimum 
loss of messages following closedown or system failure. Information about the 
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status of ACF/TCAM's environment is periodically recorded in a checkpoint 
data set; this is called taking a checkpoint. If ACF/TCAM closes down or if a 
system failure occurs, checkpoint records are used to re-create the environment 
when ACF/TCAM is restarted. 

Messages queued in main storage only cannot be checkpointed; that is, they 
cannot be recovered after a system failure or closedown. Messages queued on 
direct-access storage devices can be accessed when ACF/TCAM is restarted. 
In order to recover main-storage message queues, the customer must have a 
backup message queue data set on one or more direct-access storage devices. 

When the checkpoint/restart facility is used for network control programs, 
ACF/TCAM maintains a checkpoint data set for each network control 
program in the domain. Checkpoint records are written when certain changes 
occur in the status of a data link or remote station. 

Network Recovery: When failures occur in the network, the network operator 
can issue operator commands that permit: 

• A backup data link (either switched or nonswitched) to be activated to 
replace a failed link 

• Resources to be switched from one domain to another 

Additional network recovery capabilities are available with ACF/TCAM, 
Version 2, Release 3; these are discussed in Chapter 3 under the topic 
"Improved Network Recovery." 
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Chapter 2. Summary of New Capabilities in ACF/TCAM, Version 2, Releases 1 
and 2 



This chapter describes functions provided by Version 2 of the ACF/TCAM 
program productjs^teMj^slojyersion - l.P,f ACF/TCAM. These functions 
are available for both single- and multiple-domain networks except as noted. 
In addition to the individual new functions described in this chapter and in 
Chapter 3, Version 2 of ACF/TCAM provides the following general 
enhancements: 

• Improved assembler performance for large message control programs 

• Default bind images for externally initiated LU-LU sessions 

• The capability of cancelling operator commands in a user's message handler 

• Blocking of outbound messages going to a communications controller 

i i 

New Capabilities in ACF/TCAM, Version 2, Release 1 

The new items for Version 2, Release 1 of ACF/TCAM are grouped under the 
headings (1) installability and usability enhancements, (2) communication 
network management, and (3) enhanced data communication capabilities. 

Installability and Usability Enhancements 

The structure of ACF/TCAM, Version 2, and its related programs is different 
from earlier versions of TCAM. This fact, coupled with the addition of the 
items listed below, makes Version 2 of ACF/TCAM easier to install and use 
than earlier versions: 

• An initiator program 

• System service programs 

• A model message control program 

• Additional service facilities 

• Enhancements to the Multisystem Networking Facility that expand the 
networking capabilities defined by Systems Network Architecture 

The ACF/TCAM Initiator Program 

With earlier versions of TCAM, the operating system's reader/interpreter 
reads the JCL for the message control program (MCP), causing it to be 
executed as the job-step task. An MCP failure could cause all of TCAM to 
fail. The job-step task of Version 2 of ACF/TCAM is the ACF/TCAM 
initiator (program); it monitors the ACF/TCAM region, and in turn, invokes 
the message control program and system service programs as subtasks. Figure 
2-1 shows these differences between earlier versions of TCAM and 
ACF/TCAM, Version 2; each program is invoked by the program in the 
surrounding block. 

ACF/TCAM's task-subtask structure allows the message control program and 
the system service programs to execute asynchronously, with the initiator 
program monitoring their operation. Initiator commands may be entered from 
the system console to initiate or terminate a subtask or to display status 
information. Informational messages are displayed when subtasks are initiated 
or terminated (either normally or abnormally). 
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Figure 2-1. ACF/TCAM, Version 2, Compared to Earlier Versions of TCAM 
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The initiator should have the highest priority in the operating system; it 
continues to execute when a subtask fails and can automatically restart a failed 
subtask after optionally taking one of several types of online dumps. This 
scheme bypasses the job management overhead otherwise required to restart 
the region or partition. The initiator can also associate a backup program with 
a subtask; if the subtask fails, and continues to fail when restarted, the backup 
program can be initiated instead of the failing program. 



System Service Programs 



System service programs are sublasks of ACF/TCAM's initiator program, as is 
the message control program. (See Figure 2- 1 .) Four of the IBM -supplied 
system service programs are described below; two others are described under 
the topic "Extending ACF/TCAM's Networking Capabilities" later in the 
chapter. Optionally, the customer can write additional system service 
programs. 



Basic Operator Control System Service Program: This program is required; it 
includes commands required to keep a single- or multiple-domain network 
operational. The function and use of this program corresponds to that of the 
operator control facility in earlier versions of TCAM. 

Extended Operator Control System Service Program: This optional program 
provides commands that can be used in some phases of network operation, but 
that are not required to control the network. Extended operator commands are 
required to use ACF/TCAM's extended networking capabilities, described 
later in the chapter. 



Online Retrieval System Service Program: This program allows disk-queued 
messages (either sent or unsent) to be retrieved when an extended operator 
command is issued from an authorized station or application program. Message 
retrieval can be restricted to messages entered or transmitted on a specified day 
or unrestricted to include all messages entered or transmitted. Single or 
multiple messages may be retrieved based on a message's: 

Origin 

Destination 

Origin and destination 

Input sequence number 

Output sequence number 

Time of transmission 



Save/Restore Message Queues (SMQ) System Service Program: This 
program allows an installation to perform a cold restart without losing 
disk-queued messages; this is useful when a warm restart is not wanted or is 
impossible because of changes made to the message control program that 
require it to be reassembled. When invoked with an SMQ command entered at 
the system console, the SMQ program searches the message queue data set for 
unsent messages either on all queues or for specifically named queues. After 
finding the messages, the program writes them on a sequential storage medium 
(such as magnetic tape). Another SMQ command causes the program to read 
the messages from the tape and restore the disk with the message queue data 
set. (SMQ commands are neither basic nor extended operator commands.) 
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Model Message Control Program 

A model message control program (MCP) is shipped as part of the 
ACF/TCAM program product. The model defines a network; if this network 
meets an installation's needs, the model can be used as it is shipped. If an 
installation's requirements do not correspond to the functions supplied in the 
model, the model can be modified and then used. In any case, the model MCP 
provides examples of the correct use of ACF/TCAM macros and can be useful 
even when an installation defines its own MCP. 

Additional ACF/TCAM Service Facilities 

ACF/TCAM service facilities execute under control of the message control 
program and are invoked as needed. (See Figure 2-1.) In addition to the 
service facilities available with earlier versions of TCAM, Version 2 of 
ACF/TCAM includes the three described below. 

Startup-Restart Message Generation Facility: This facility makes it easier for 
an installation to have variable-content messages generated and sent following 
startup or restart of the message control program. 

Security Authorization Service Facility: This facility permits only authorized 
stations to access certain applications or system service programs (basic and 
extended operator control, and online retrieval). In conjunction with the 
authorization facility, ACF/TCAM maintains access-authorization flags in 
option fields (from the OPTION macro) associated with the stations. When a 
security breach is attempted from an unauthorized station, an 
installation-defined procedure can be initiated; for example, notifying a central 
security monitor after rejecting the unauthorized action. 

Dynamic Accounting Service Facility: This facility allows an installation to 
accumulate statistics on network utilization for eventual analysis by online or 
offline user-written programs; the statistics are gathered online. This 
information can be used for problem determination or for network 
management. 

Extending ACF/TCAM's Networking Capabilities 

The Multisystem Networking Facility (MSNF) is an optional feature of 
ACF/TCAM that permits multiple-domain networks to be created. (See 
"Network Characteristics" in Chapter 1.) ACF/TCAM's MSNF functions are 
divided into basic networking functions, which are generally applicable to all 
SNA-based networks, and extended networking functions, which build upon 
the basic functions by using host-to-host data flows. Extended networking 
functions are not architected as part of SNA, but are designed to complement 
SNA capabilities. 

In ACF/TCAM, Version 2, Release 1, SNA allows only one route to be 
defined between the subarea originating message traffic and the destination 
subarea (end subareas) \ ACF/TCAM's extended networking utilizes one or 
more of these routes to form extended routes. An extended route is a series of 
one or more SNA routes that connect one host node to another host node in an 



^n terms of ACF/TCAM, a subarea is the collection of network resources controlled by 
either a message control program or a network control program. With ACF/TCAM, 
Version 2, Release 3, up to eight routes can be defined between end subareas. Refer to 
"Multiple Routing" in Chapter 3 for additional information. 
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extended route. With extended networking, a destination subarea for an SNA 
route might be a "stopover" in an extended route; from that point, 
ACF/TCAM uses another SNA route to send the traffic to either its 
destination subarea or to another stopover. By using SNA routes in this 
manner, ACF/TCAM can provide more than one extended route between two 
host nodes; this capability allows: 

• An alternate extended route to be used when the primary extended route is 
inoperative 

• Multiple extended routes to share the data traffic flowing between two host 
nodes 

Extended routes, alternate extended routes, and multiple extended routes are 
totally separate concepts from parallel links, multiple routing, and the alternate 
SNA routes discussed in Chapter 3. Though totally separate, extended 
networking and the capabilities available with ACF/TCAM, Version 2, 
Release 3, can be used together to provide an installation with many 
possibilities for message traffic flow and network backup. 

Data flowing on an extended route flows through one or more utility sessions. 
Utility sessions exist between host nodes in the extended network and are used 
to send data from host to host. (See Figure 2-2.) Utility sessions allow message 
traffic to be automatically rerouted to its destination over an alternate 
extended route when a physical element in the primary extended route fails. In 
addition to extended routing and utility sessions, ACF/TCAM provides 
extended networking capabilities by using: 

• An internodal routing facility, based upon ACF/TCAM's ability to route 
messages by keys and using extended routes. 

• The internodal awareness system service program, which is present in each 
host node; the program monitors the availability of other host nodes and 
selected applications in the network and broadcasts the availability status to 
the other host nodes. 

• The internodal sequence number synchronization system service program, 
which is used to recover from transmission errors when they are detected. 



Transmission Categories in an Extended Network: In a typical 
multiple-domain network, different classes of traffic related to different 
application types have characteristics that require specific types of system 
support. For example, applications may differ in the way that they need to 
respond to failures. In addition, in a network with a mixture of application 
types, it is important to balance urgency to cost; for some nonconversational 
applications, fast delivery is not important, while for other applications, it may 
be critical. It is also very desirable to limit the use of data links between 
domains and guarantee conversational response time by controlling the flow of 
low-priority, high- volume traffic. 

ACF/TCAM's extended networking allows an installation to define 
transmission categories; a transmission category is a user-defined group 
containing a subset of the messages flowing over utility sessions in the 
extended network. The network designer perceives all messages in the same 
transmission category as having similar characteristics, specifies handling 
characteristics that will define each transmission category, and decides which 
types of applications will be assigned to each category. Different ways of 
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A, B, and C are ACF/TCAM, Version 2 

a, b, and c are ACF/NCP/VS 

The SNA route defined between A and C is: 

This also corresponds to the primary extended route defined between A and C. 
An alternate extended route between A and C cou|d be: 

Utility sessions exist between: 

A and B (A->-a — *-b — ►B) 

A and C (A-*-a — ►b — *-c — *-C) 

B and C (B— *-b — ►c — *-C) 

Figure 2-2. The Relationship between SNA Routes and Extended Routes 

performing the following ACF/TCAM operations may be applied to messages 
in different transmission categories: 

Queuing messages (in main storage or on disk) 

Message priority 

Sequence checking 

Error handling 

Load balancing 2 

Data Staging 3 



An ACF/TCAM extended network may use up to sixteen transmission 
categories for specialized message handling. The message control program for 
each host node in an extended network has defined within it the transmission 



2 Load balancing is the distribution of the data traffic between two hosts among all available 
extended routes connecting them. 



3 Data staging uses utility sessions to move high-volume, low-priority message traffic from 
host to host, progressively approaching the destination host. 
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categories that can be used with each other host in the network. Transmission 
categories provide the network designer with a manageable way of grouping 
like data and of ensuring uniform treatment of all data in the same class of 
traffic. Transmission categories can be used in conjunction with the 
class-of -service capability available with ACF/TCAM, Version 2, Release 3; 
refer to "Multiple Routing" in Chapter 3 for additional information on class of 
service. 

Summary of the Enhancements Provided by Extended Networking: Extended 
networking supports large networks having different types of applications by 
providing: 

• Generalized host-to-host data flow support for data-collection, 
data-distribution, and transaction-routing applications 

• A rational division of different types of cross-domain message traffic into 
transmission categories, and a means of specifying different types of 
message handling and scheduling for different transmission categories 

• Data staging and load balancing capabilities 

• Preservation of message priority levels across domains 

Extended networking provides error-recovery procedures, including: 

• Automatic rerouting of messages over an alternate extended route (using 
different utility sessions) to the destination in the event of a failure of a 
cross-domain link, an ACF/NCP/VS, or a host on the primary extended 
route 

• Automatic monitoring of the availability of cross-domain host nodes, and 
applications, and optional rejection of messages whose destination node or 
application is currently unavailable 

• Automatic assignment and checking of output sequence numbers for 
internodal message traffic (traffic between host nodes), and automatic 
retransmission of messages when a sequence-number gap is detected 

ACF/TCAM provides a set of macros for defining the extended network, 
including macros that expand into message handlers for handling cross-domain 
message traffic. ACF/TCAM also provides model message control programs 
that can facilitate the task of defining certain types of networks. 

Communication Network Management 

Version 2 of ACF/TCAM includes additional problem- determination and 
network-operation functions that can assist in optimizing management and 
control of a customer's network. 

Enhanced SDLC Data Link Testing 

ACF/TCAM has two new tests that can be performed to verify that 
communication has been established between a host processor and an SNA 
station (cluster node or terminal node). One, the SSCP-LU echo test, is 
performed by an SNA-station operator; the other by the network operator. 

A station operator initiates a test by entering a test request. The host replies 
with either the test message sent by the operator in the test request or with the 
default test message. The host transmits the test message as many times as the 
terminal operator specified or as many times as defaulted to in the test request. 
Although this test cannot be run across domain boundaries, it is still useful 
when cross-domain problems occur; that is, the terminal operator can 
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determine whether the station's connection to its owning host is part of the 
problem. This test can run with NCP/VS, Version 5, and any release of 

ACF/NCP/VS. 

The network operator initiates a test by entering a test request from the 
operator control station specif ying the SNA station to be tested, a test message 
(optional), and the number of times the test message is to be sent. The SNA 
station (cluster node or terminal node) being tested must be on a nonswitched 
data link. The test determines whether the station being tested is 
communicating with its owning host. Communication between the host and 
other stations on the data link is not disrupted. Test results are sent to the 
operator control station. This test requires either Release 2 or 3 of 
ACF/NCP/VS. 

Intensive Mode Error Recording 

Normally during error recovery, the network control program records the initial 
error status that started the error recovery process; for permanent errors, it also 
records the final error status that caused a permanent error record to be built. 
The network control program does not ordinarily record information about 
temporary errors that may occur between the initial error status and the final 
error status. However, when the network operator issues an operator command 
requesting intensive mode error recording, the ACF/NCP/VS also records 
temporary errors. This additional information can often preclude the need for 
specific testing in an attempt to re-create an error, thereby easing problem 
determination. Intensive mode error recording has been available with 
previous versions of TCAM for remote stations that use the 2701 data adapter 
and the 2702 and 2703 control units or the communications controllers in 
emulation mode; with Version 2 of ACF/TCAM operating with either Release 
2 or 3 of ACF/NCP/VS, intensive mode error recording is also available for 
SNA stations on SDLC lines controlled by ACF/NCP/VS. 

Dynamic Reconfiguration of Remote SNA Stations 

Change is a frequent occurrence in all networks, but change becomes severe 
for installations that have: 

• Large Networks 

• Many new stations being added 

• 24-hour operation 

• Frequent configuration change requiring fast reaction time 

With Version 2 of ACF/TCAM, an installation can selectively add remote 
SNA stations to or delete them from a network; the stations must be on 
nonswitched lines. This capability allows an installation to: 

• Change the network without regenerating the ACF/NCP/VS or reloading 
the communications controller 

• Bypass a failure in the SDLC link between a communications controller and 
a remote station by dynamically reassigning the affected physical and logical 
units to. a backup link 



Enhanced Network-Control-Program Storage Display 

With Version 2 of ACF/TCAM, the network operator can issue one command 
that will display up to 256 bytes of contiguous storage in the 3705 
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Communications Controller. With previous versions of TCAM, only 32 bytes 
could be displayed. The Display command can be issued while the network 
control program is operating. This capability reduces the need to stop, reload 
the network control program, and restart the network in order to collect 
problem-determination information. 

ACF/TCAM's Support of New Problem-Determination Products 

The Network Communication Control Facility and the Network Problem 
Determination Application program products can be used with Version 2 of 
ACF/TCAM. These products offer an installation programmed assistance for 
problem determination and network operation. More information about these 
program products is in the following publications: Network Communication 
Control Facility General Information, GC27-0429, and Network Problem 
Determination Application General Information, GC34-2010. 

Enhanced Data Communication Capabilities 

Version 2 of ACF/TCAM provides improved flexibility for SNA session 
operation, data security, and support for additional devices. 

Negotiable Session-Initiation Parameters 

An SNA Bind Session request (referred to here as a Bind request) sent from a 
primary logical unit to a secondary logical unit establishes an SNA session. The 
Bind request contains a set of protocols (Bind parameters) that will be followed 
during the session. With Version 1 of ACF/TCAM, the secondary logical unit 
had to either accept the Bind request it received or reject it. With Version 2 of 
ACF/TCAM, the primary and secondary logical units can "negotiate" on 
which parameters to include with the Bind request as follows: 

1 . The Primary Logical Unit (PLU) issues a negotiable Bind request with 
the parameters defined for the request. 

2. Upon receiving the request, the secondary logical unit (SLU) can accept 
the request, reject it, or change certain parameters if they disagree with 
the session protocols that the SLU wants. 

3. If the PLU receives a changed Bind image and accepts the modified Bind 
parameters, normal data traffic begins for the session; otherwise, the PLU 
sends an Unbind request. The PLU can again attempt to establish the 
session by sending either a nonnegotiable Bind request or another 
negotiable Bind request. 

The negotiable Bind request relieves the primary logical unit of having to store 
Bind parameters for all types of secondary logical units. Use of the Negotiable 
Bind request can simplify network definition and reduce the amount of storage 
used for Bind Parameters. Both session partners must support the use of 
negotiable Bind Session requests. 



Other Enhancements 



In addition to the use of the negotiable Bind request, ACF/TCAM enhanced 
capabilities include: 

• The capability of using IBM's Programmed Cryptographic Facility program 
product. The cryptographic facility allows data flowing in LU-LU sessions 
to be encrypted and decrypted, thus offering an installation a means of 
securing data transmitted in the session. 
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Local attachment of the 3274 Control Unit and 3790 System. These 
systems can be used in both single- and multiple-domain networks. 

Use of the IBM 3705-11 Communications Controller, Models J, K, and L 
ACF/TCAM can operate with these models as local controllers, remote 
controllers, or both. 



New Capabilities in ACF/TCAM, Version 2, Release 2 

ACF/TCAM's Subsystem Support 

Release 2 of ACF/TCAM, Version 2, through a compatible subset of 
ACF/VTAM's record application interface (API), will provide support for all 
ACF/VTAM functions being used by the subsystems listed below. Consult 
your IBM representative for the applicable versions and releases of the 
subsystems. 

Customer Information Control System (CICS) 4 

Distributed System Executive (DSX) 

Information Management System (IMS) 

Job Entry System 2 and 3 (JES2 and JES3) 

Host support for the IBM 3650 Programmable Store System 

Virtual Storage Personal Computing (VSPC), OS/VS1 only 

At execution, the customer's job stream must indicate that the ACF/TCAM 
subsystem interface is to be used instead of the ACF/VTAM record API; the 
function provided by ACF/TCAM is the same as that provided by 
ACF/VTAM. Subsystems in different hosts can communicate over a single 
session using ACF/TCAM's subsystem interface. The diagram that follows 
shows the difference between the path of a message destined for a 
customer-written application program and the path of a message destined for a 
subsystem. 



4 CICS can continue to use the GET/PUT interface as in previous versions of TCAM; with 
ACF/TCAM, Version 2, Release 2, CICS can also use the subsystem interface. 
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/Vote: The user may optionally specify a DMH, or a DMH and an AMH to perform limited editing of messages; 
only a restricted subset of message-handler functions can be used for this purpose. 



As shown in this diagram, ACF/TCAM does no message queuing when a 
customer accesses the services of a subsystem. The chart that follows 
summarizes the relationship between ACF/TCAM, Version 2, and other 
host programs in the network. 
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Chapter 3. Summary of New Capabilities for ACF/TCAM, Version 2, Release 3 

Level 3 of Advanced Communication^ Eunatioja^CA^F) provides new functions 
Itnat can imprbve'lne reliability, availability, serviceability, and usability of 
SNA-based networks 1 . The combination of ACF/TCAM, Version 2, Release 
3, and ACF/NCP/VS, Release 3, increases the options that an installation has 
when configuring and managing its network. Release 3 of ACF/TCAM, 
Version 2, also offers additional means of determining the causes of problems 
in the network. Each new function of ACF/TCAM, Version 2, Release 3, is 
discussed in the topics that follow. 

In this chapter, the term "network control program" refers to the IBM 
ACF/NCP/VS program product. 

ACF/TCAM's Support of Extended Network Control Program Interconnection 

Prior levels of ACF impose constraints on the location in a network of 
communications controllers and their network control programs. 
For example, a remote contrjQller.,canrji.ot be„c.Qnnected to more than one local 
^cmUroJIerjnioi; can itbe connected, in turn, to another remote controller 2 . 
These constraints limit the numSer of possible network configurations and 
restrict the number of paths over which network traffic can flow. Figure 3-1 
shows two host processors, each connected to a channel-attached 
communications controller. Each channel-attached controller is connected in 
turn to a link-attached controller; the two channel-attached controllers are 
joined by a data link. Under prior levels of ACF, no other links can connect 
the controllers to each other. 

Release 3 of ACF/NCP/VS provides the same functional capabilities for both 
channel-loadjed and lmk^oj^ Any "controller can 

be connected to any other controller in the network. Figure 3-2 shows a 
configuration with each controller now linked to every other controller. Figure 
3-3 shows how link-attached controllers can be joined in tandem; of the 15 
possible connections between controllers, 11 are shown. The topics "Multiple 
Routing," "Improved . HfeteQfk Recovery," and "Cojrn°igur^ 
later in this chapter explain the advantages of having these added connections. 

NpjwjsrX .control programs (NCPs) and SDLCJinj^cjm^bejhared concurrently 
by muhiplejSSCPs,, regardless of where the NCPs and links are located in the" 
network. Improved shareability of resources, together with the availability of 
alternate routes^ between subareas, fjcjlitates ijan SSjCJls,aMljtXio |^£oy e x r 
control oTalresource whejnjhecurrent ownerXSSXIEL,Qr_the path to that 
owner, has become mopexatiye. These capabilities, along withTftelS^CFfestart 



^evel 3 of Advanced Communications Function (ACF) includes ACF/TCAM, Version 2, 
Release 3; ACF/VTAM, Release 3; and ACF/NCP/VS, Release 3. If you are unfamiliar 
with SNA concepts and terminology, you should read Chapters 2 and 3 of Introduction to 
Advanced Communications Function, GC30-3033. Most of the information in Chapter 4 of 
that manual is included here in this chapter. 



2 Use of the terms local controller and remote controller is explained in Chapter 1 under the 
topic "Communications Controllers." 
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Figure 3-1. Links between NCPs Supported by 
ACF Level 2 



Figure 3-2. Links between NCPs Supported by 
ACF Level 3 
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Figure 3-3. Links between NCPs Supported by ACF Level 3-Tandem Remotes Added 
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Parallel Links 



and SSCP tak eover functions described later in this chapter, can improve the 
availability of a network— that is, its ability to continue functioning despite 
temporary failures of certain of its elements. Refer to "Improved Network 
Recovery" later in the chapter. 



With Release 3 of ACF/NCP/VS,_two network control programs can 
communicatejiimultane^^sly^oyer two or more SDLC links, called parallel ',, 
links'. Any nurribeFoflinks bej; weenj^ ap.ei.ate 

^ncurrently; hardware capabilities (such as line sets) determine the number of 
links that can be physically installed between the 3705s. The characteristics of 
the links may differ; some may be high-speed links, while others may be 
low-speed links. JEach link can be ^activated I and deactivated independently of 
the other links Jjet ween the network control programs. 

Parallel links, when used in. conjunction with the transmission group capability 
(described in the next topic), can increase the message flow between two 
network control programs. Also, by distributing the total data flow among 
multiple links in transmission groups, an installation can minimize the 
disruption to SNA sessions caused by failure of a single link or by the need to 
deactivate a link for reasons such as maintenance or testing. Parallel links 
provide a basis for alternate. routin£_of messages between two adjacent 
subareas. With alternate routing, the data that would ordinarily flow over an 
inoperative link is automatically redirected over the remaining links in the 
transmission group. Thus, the reliability and availability of the paths between 
network control programs are improved. (Refer to ACF/NCP-SSP General 
Information, GC30-3058, for addition information on parallel links.) 



Transmission Groups 



Multiple, active SDLC links bjgtween network , control j^rqgra.ms can be grouped 
logically so as to appear to the network as a single logicaLconnection. The 

term transmission group is usecl to represent a logical connection between two 

network control programs, evenjfjtjjej'.graup'' contains only one link. The 
f term als(^r^£r£s^njtsjhe Jpjiicjil connection between the hosTpFocessor and the v 

network control program, even thougK "this i oSmSection consists only^ of a single 

data~channel. ~- - . ^■--■-'■■■■"■-■'"°~'-"~"""** 



Two network control programs can be joined by up to eigJiUraji^m^ 
groups; anxjy£i^e4ink.ca^^ transmission grjoufj. Each 

"network control program djy^mically di^ data traffic among 

J^jpjarr^ Failure or deactivation of 

any of the active links in the group (so long as it is not the sole remaining link) 
results in automatic redistribution of data traffic among the remaining links 
without disruption of any of the sessions currently in progress using those links. 
Application programs and user (LU-LU) sessions are entirely unaware of and 
not concerned with any redistribution of traffic within a transmission group 
due to an inoperative link. Figure 3-4 shows five links between network 
control programs divided into two transmission groups. 

There is no limit ojijUhe^number of links that maxfornia^ 
except for any limits imposed by the line attachment hardware of the 
communications controller. However ,j^ links^^ 

group should hayejknilar characterj.stics such_a£lhie speeds and propagation 
~~™ "~7s7 "This is recommended because data traffic is assigned to any available 
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Figure 3-4. Two Transmission Groups between NCPs 



link in a group regardless of the individual link characteristics. Take as an 
example a group that includes two links, one operating at 2400 bits per second 
(bps) and the other at 9600 bps. While the 2400 bps link is transmitting data, 
any other traffic that arrives is assigned to the 9600 bps link. Because PIUs 

I ( must be placed in correct sequence at the receiving end of the transmission 

\ \ group, it is possible that many PIUs transmitted over the 9600 bps link would 

I I have to wait on a queue at the receiving end while a PIU which must be 
/ l processed before them is being transmitted over the slower link. 

SDLC links need not be associated with transmission groups when the network 
f control programs are defined. Only when a network control program activates 
l a particular link upon command from ACF/TCAM does the actual link become 
\ associated with a particular transmission group. A switched link may be moved 
) from one transmis^ to help equalize traffic loads or to 

/ "compensate for link failures. 



Multiple Routing 



With e arl^ betwee n a^pair 

of subareas. All data traffic sent by sessions established between those 
subareas is transmitted over that single route. Any failure of a physical 
element of the route, such as a link, interrupts all SNA sessions using that route 
and their data traffic until the failing element is restored or another element 
(such as a backup link) is substituted for the failing element. Then SNA 
sessions must be reestablished and resynchronized before transmission of user 
data can resume. 



An SNA-based network controlled by Level 3 of ACF can have up to eight 
different physical routes between the same pair of subareas. This capability, 
multiple 'Touting, can greatly improve the reliability and availability of a 
network and reduce network disruption caused by failed network elements. 
Figure 3-5 shows two subareas (host A and network control program B) joined 
by four different routes. 
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.Each SNA session between.jLJBSJrjof subareas is associated with a specific 
j^oute; several SNAliessions may be associated with the same route. Figure 3-6 
shows the configuration of Figure 3-5 with sessions added. All data within a 
given session flows over the same route; that is, session data flow is not divided 
^among jroutes. The availability of multiple routes allows the total number of 
SNA sessions between a pair of subareas to be distributed among the routes. 
When failure of a physical element in one route makes that route inoperative, 
the sessions using that route are disrupted. New sessions to replace those 
disrupted by route failure may be established over any of the remaining routes, 
as desired. Figure 3-7 shows how failure of one route can result in its sessions 
being reestablished over the remaining three routes. 
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Figure 3-6. SNA LU-LU Sessions between Subareas Distributed over Four Routes 
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Figure 3-7. SNA LU-LU Sessions of a Disrupted Route Distributed over Remaining Operational Routes 
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Multiple routing may be considered at a physical level and at a logical level. 
The term applied to the physical level is explicit routing. A n explicit route is a 
sequence of physical network elements (such as links and controllers) over 
which two subareas communicate. Examples of physical elements are host 
processors, communications controllers, and the transmission groups (links and 
channels) that connect them. Up to eight explicit routes can be established 
J3ejwejejo_ajay_two^ Two or more explicit rout es mayMve~certain " 

physical element s (or al l elements )Jn^oinmon. For instance, a single 
transmission group or a single network control program may be an element in 
several explicit routes, as shown in Figure 3-8. 
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EXPLICIT ROUTE 1 



S 



3705 
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3705 



Figure 3-8. Explicit Routes Sharing Physical Elements (Two 3705s and One Transmission Group) 

The logical level of routing is called virtual routing. A virtual route is a logical 
-S°2£?£t^^ participate in SNA sessions. Each 

virtual route in a network is bidirec tional an c[ associated with an explicit route x 
A given explicit route can accommodate multiple virtual routes. 

An explicit route is a combination of physical network elements, each of which 
has certain data transmission characteristics, such as bandwidth and 
transmission rate. The reliability of an element also may be considered as one 
of the characteristics. The combined characteristics of all of the elements that 
form the explicit route determine the data transmission characteristics of that 
route. Because a virtual route is supported by an explicit route, it assumes the 
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characteristics of the explicit route, and has an important additional 
characteristic: transmission priority. 



Level 3 of ACF allows three levels of tra nsmission priority , which are assigned 
to data flowing in SNA sessions on a virtu al-r outebasis . This route-level 
transmission priority is important because data transmission requirements for 
SNA sessions vary. For example, inquiry/reply sessions usually require faster 
data transmission and more predictable response times than data collection 
sessions. Since sessions for several different kinds of applications may be in 
progress over a given route, data for sessions requiring fast data flow can be 
transmitted ahead of data for sessions in which slower data flow is acceptable. 

The three route-level transmission priorities, combined with the eight possible 
virtual route numbers, allow up to 24 virtual routes between two subareas. A 
given explicit route can accommodate many virtual routes. The virtual routes 
supported by a given explicit route have in common the explicit route's inherent 
physical attributes; the virtual routes differ only in their relative transmission 
priorities. 

^TjhjjjjyjsJ^n^^ for each kind of session 

between a pair of subareas (that is, inquiry/reply LU r TirsessTmi7SSnF : T r U 
session, etc.) the virtual routes^ with chara^e^istics^best.m atching the 
requirements of that kind of session, relative to the requirements of other kinds 
of sessions. In making the selection, the programmer must consider the 
physical characteristics of the explicit routes to be used along with the 
route-level transmission priority. Some explicit routes, and therefore the 
corresponding virtual routes, may be inherently better than others. Explicit 
routes that comprise fewer physical elements in tandem; for example, would be 
typically favored over those having more elements. The longer routes might be 
used only for backup purposes when the shorter routes become inoperative. 

Sometimes several virtual routes may have approximately the same 
characteristics and therefore be equally suitable for transferring data during a 
given kind of SNA session. ACF/TCAM, Version 2, Release 3, allows a 
programmer to spjegjfxajist of sever al virtual routes to which a session may be 
assigned. The list of one or mo_re_yirtual routes represents the class of service 
furnished to a session. A class of service is associated with an SNA session 
when the session is established. ACF/TCAM host LUs can explicitly specify a 
particular class of service name. If none is specified, a default class of service 
is assigned to the session. The SSCP resolves the class of service name to a list 
of virtual routes, from which one virtual route is chosen at session initiation. 
The selected virtual route remains assigned until the session ends. 

ACF/TCAM and network control programs activate and deactivate virtual 
routes as needed. They also activate (but do not deactivate) explicit routes 
associated with the virtual routes. Network operators do not activate or 
deactivate routes of either kind, but they do activate and deactivate the NCPs 
and links that form explicit routes. 

If none of the virtual routes in the virtual-route list is available, the request to 
establish the SNA session is rejected. A later attempt must be made to 
establish the session. ACF/TCAM provides a virtual-route-availability 
monitoring option that allows the host LU to be notified automatically when a 
virtual route in the requested virtual route list becomes available. When the 
LU is notified, it may automatically retry the session-initiation request. 
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Transmission categories (discussed in Chapter 2 under "Extending 
ACF/TCAM's Networking Capabilities") are independent of class of service. 
However, the network designer can define classes of service that accommodate 
specific transmission categories. For example, a utility session supporting a 
transmission category designed for data-staging applications may be assigned 
one class of service, while a utility session supporting a transmission category 
of inquiry /reply applications may be assigned another class of service. 

Network Flow Control Enhancements 

The flow of data through a network varies from time to time; many networks 
anticipate and plan for peak data traffic conditions during the conduct of 
business. Traffic peaks can also result from conditions such as the failure of a 
virtual route and the consequent diversion of its traffic to an alternate virtual 
route. The alternate virtual route may become overburdened with the extra 
traffic it is asked to carry. Unexpected demands for data transmission by 
certain end users (individuals or application programs) also may impose peak 
traffic conditions on parts of the network. Thus, not only does the total traffic 
in a network vary, but the distribution of the traffic in various parts of the 
network may vary as well. 

Whenever the rate at which data is presented to a network exceeds the capacity 
of the routes over which the data must flow, data congestion occurs. Severe or 
prolonged congestion in one part of a network may be propagated to other 
parts, causing overall network efficiency to suffer. On a network-wide basis, 
network control programs continuously monitor data flow over transmission 
groups and signal any congestion to network resources (network control 
programs and access methods) which are the endpoints of the virtual routes 
supported by the congested transmission groups. The access methods and 
network control programs then react by limiting the amount of data they send 
over the affected virtual routes until the congestion clears. The monitoring of 
data flow and limiting of data occur automatically, requiring no action by end 
users. 

Congesti on indicat o rs that can be set in r )ajLhmformation unjts^PTUsj^are the 
means of signaling congestion. For example, a network control program can 
set a congestion indicator upon detecting that its queue for a particular 
transmission group is overloaded or if the program is in slowdown mode 
because its buffers are depleted. ACF/TCAM sets congestion indicators (1) 
when the number of main-storage units used reaches installation-defined 
thresholds or (2) when the reusable message queue data set on disk is being 
reorganized and the reorganization subtask is unable to keep up with the flow 
of new message traffic. The flow-control mechanism in the access methods 
and network control programs interpret the congestion indicators and modify 
the algorithms by which traffic is allocated to virtual routes in a way that 
causes the congestion to dissipate. The term r^ute_pacing is applied to the 
monitoring and flow-control mechanism used to alleviate congestion on virtual 
routes. 

ACF/TCAM provides flow control for LU-LU sessions when the logical unit 

is: 

• A subsystem. Requests and responses from the subsystem are queued in the 
subsystem's address space until the required path is cleared of congestion. 
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• A message handler. The user specifies the maximum number of buffers that 
can be concurrently assigned to the destination logical unit. This number is 
initially assigned when the message control program is defined; it can be 
overridden when the LU-LU session is established. 

• A channel-attached cluster controller containing an LU which is in session 
with an LU in another subarea. When inbound pacing is used, the 
session-level pacing response is withheld whenever the virtual route carrying 
its session is congested. When no inbound pacing is performed for the 
cluster controller, no data is read from the entire cluster while the LU-LU 
session for any LU of the cluster is using a congested virtual route. 

Network Problem Determination 

Level 3 of ACF provides improved capabilities for determining the cause of 
failures in a network. These, known collectively as network problem 
determination capabilities, facilitate identifying the physical elements that have 
failed. 

Session Outage Notification 

In a network controlled by Level 3 of ACF, any interruption of a virtual route 
causes the ends of the sessions using that route to be notified in a procedure 
called session outage notification. Data flowing along a route in a network 
passes through a series of network elements, all of which must be operational. 
All network routes are subject to interruption through failure (or deactivation) 
of any of their elements. When such a failure occurs, all sessions using the 
affected route are disrupted and the end users are notified. Network elements 
that can fail and therefore cause session disruption (also called session outage) 
are: 

• A host processor or its software 

• A data channel 

• A communications controller or its network control program 

• A link between network control programs (if the link was the last 
operational link in a transmission group) 

• An SNA station 

• An SDLC link or channel connection to an SNA station 

Many elements of an SNA-based network, such as SSCPs and network control 
programs, contain information about the current status of ongoing LU-LU 
sessions. This information normally passes along the SSCP-SSCP and 
SSCP-LU sessions associated with the LU-LU sessions. When a failure in the 
network disrupts a session, it is important that this changed status of the 
session be communicated not only to the session partners, but also to all other 
affected SNA network functions (such as SSCPs). 

In ne tworks using prior le vels of ACF^the notificati on is communicated alon g 
^die_S^CT-SSjCP_session.~Some failure^Tiowever, can^disrupt the SSCP-SSCP 
session along with the LU-LU session, thus preventing notification of session 
outage from reaching affected SNA functions. For example, an SSCP that 
owns an LU for which an LU-LU session has been disrupted may not learn of 
the disruption and therefore be unable to allow another session to be 
established with that LU. 

A network controlled by Level 3 of ACF does not rely on the continued 
existence of an SSCP-SSCP session to communicate information about 
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Route Verification 



disruption of an LU-LU session. Instead, when a failure disrupts any kind of 
SNA session (CDRM-CDRM, SSCP-PU, SSCP-LU, or LU-LU), network^ 
co ntrol program s a nd access meth ods on either side of t he disruption n otify the 
session partners, and all other affected SNA functions and network operators, 
of the occurrence of the outage. 

The improved notification available with Level 3 of ACF provides increased 
opportunities for sessions to be reestablished, especially if alternate routes are 
available. 



Route verification allows the network operator to verify that any or all explicit 
routes between the ACF/TCAM subarea and any other subarea are active and 
usable- The ACF/TCAM SSCP sends test data on explicit routes associated 
with virtual routes in a specified class of service. If the explicit route is 
operational over its entire length, the destination subarea responds to the 
testing host node, which in turn notifies the operator that the route is 
operational. If a failed (or inactive) physical element causes the explicit route 
to be inoperative, the subarea that detects the failed (or inactive) element 
notifies the ACF/TCAM SSCP. The notification identifies: 

• The number of the inoperative explicit route. 

• The subarea that detected the inoperative explicit route. 

• The ID of the transmission group corresponding to the next part of the 
route. The ID is composed of subarea number of the next node in the explicit 
route and the number of the failing transmission group. 

• The subareas at each end of the explicit route. 

• The reason code for the failure. 

The notification isolates the failure to a specific transmission group or subarea. 
The subarea detecting the failure also notifies all its owning SSCPs that a 
route-verification test failed and identifies the subarea that originated the test. 
The SSCPs in turn pass this information to their respective network operators. 

ACF/TCAM also provides an operator command that allows the operator to 
display the status of a transmission group; with this command, the operator can 
learn: 

• The transmission group number 

• The names of the links in the group 

• The subarea numbers of the two connected subareas 

• Whether a link is active within a transmission group 

Another operator command allows the operator to display the virtual route 
number and transmission priority of each session specified in the command. 

Extended Network-Control-Program Ownership 

Level JSjrfACJPjajlows ownership of any Jinkbe t ween network con trol 
programs (NCPs) to be shared amongupJo_eigliLS_SJCP_saiLthe network, 



regardless of whether the link is attached to a resource in the domain of the 
owning SSCP. Thus several SSCPs can activate a link between NCPs; 
information maintained in the NCPs reflects the current number of SSCPs that 
own (have activated) the link. Each SSCP may relinquish ownership of the 
link when it has no further use for it, without actually causing the link to be 
deactivated. Only wjien_a JDeactivate Link c ommand is received from the last 
remaining owner does the network control program actually deactivate the link. 
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In addition, Level 3 of ACF allows an SSCP to assume ownership of NCPs and 
associated resources that are not adjacent to resources currently owned by the 
SSCP; that is, with level 3 of ACF the domain controlled by an SSCP may be 
topographically disjoint. 

Dynamic Network-Control-Program Dump 

This dynamic dump facility allows the network operator to request a dump at 
any time without interrupting NCP execution or disrupting any sessions in 
progress. The dump listing does not represent a snapshot of all storage 
captured in a single instant. Instead, ACF/TCAM requests the dump data in 
256-byte segments; the data in each 256-byte segment is not necessarily 
collected at the same time. The NCP dump data set is defined as in earlier 
versions of TCAM. 

Line Trace with Transmission Group Option 

ACF/TCAM allows the network operator to issue an operator command that 
will trace a transmission group. (Refer to "Transmission Groups" earlier in 
this chapter.) The transmission group trace facility traces all path information 
units (PIUs) over the links in the group just as though the group were a single 
link. The request for a transmission group trace is specified as an option of the 
operator command used to request a line trace. The transmission group trace 
remains active as long as the associated line trace remains active. If the 
associated line becomes inactive for any reason, the line trace is terminated 
and, consequently, so is the transmission group trace even though there may be 
other active lines remaining in the transmission group. The operator may 
restart the transmission group trace by requesting a line trace with the 
transmission group option for another line in the group. 

Configuration Flexibility 

Capabilities with Level 3 of ACF give installations new flexibility in 
configuring their SNA-based networks. Two new functions are the basis for 
this new flexibility: extended network-control-program interconnection and 
extended network-control-program ownership. 

Extende d network-control-program (NCP) interconnection, allows any 
communications controller to be connected to anYother communications 
controller in the network. Link- attached controllers can be connected in 
tandem and can, thereby, be located where they are needed in the network. 
(Refer to the topic "Extended Network-Control-Program Interconnection" 
earlier in this chapter.) 

Extended network-control-program (NCP) o wnersh ip in Level 3 of ACF 
allows up to eight SSCPs, regardless of their locations in the network, to own 
the link or links between any two NCPs. With this capability, a single SSCP 
can own all network resources, including such links. In a network containing 
multiple host processors, control of the network can be vested in a single host 
processor. Trnsmultiple-processor^rrangemejrjjsjc alled a communication 
management configuration all network resources are defined in, and controlled 
"By, a single hosfcalled the communication jnanagement proc essor. The SSCP in 
the communication management processor is notified of any inoperative links 
or NCPs in the network. Prior levels of ACF allow a limited communication 
management configuration, but all SSCPs in the configuration had to share an 
NCP. 
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Level 3 of ACF also allows a host containing ACF/TCAM to exchange 
data-link-control parameters with its channel-loaded network control 
programs. After this contact is made, the host can send data throughout the 
network without owning any resources, including its channel-loaded NCPs. In 
a communication management configuration, such a host is called a data host. 
A data host does not manage any network resources; it is free to perform only 
application processing. A dat ahost contacts its channel-loaded NCPs for jiata 
routjn^jpLUrjPLO^sjonlyj it does not activate the ; NCPTor'any~oTtheir attached^ 
resources,. When defining ACF/TCAM in a datsThost, the syst^m^ogmrnmer 
does not have to define channel-attached NCP nor any of their attached 
resources. He need only define cross-domain SSCPs with which the data host's 
SSCP will communicate. A data host does not require access to the network 
control program's Resource Resolution Table (RRT). The SSCP in each data 
host is notified if any of the routes that it uses become inoperative. Locating 
problems in a communication management configuration is easier because the 
responsibility belongs to the network operator at the communication 
management processor; coordination among operators at widely dispersed 
locations is unnecessary. 

Improved Network Recovery 

New functions available with Level 3 of ACF can substantially improve the 
reliability and availability of SNA-based networks. For example, the parallel 
link capability allows an installation to distribute the total data flow among 
multiple links, thereby minimizing disruption to SNA sessions caused by failure 
(or deactivation) or a single link. 

Improved network recovery is also a major benefit of extended NCP 
interconnection. (See "Extended Network Control Program Interconnection" 
earlier in this chapter.) Improved recoverability results from removal of 
distinctions between netw ork control progra ms loaded over a data channel an d 
those loaded over a data link. Network control programs prior to 
ACF/NCP/VS, Release 3, that are loaded over a link cannot operate links to 
other domains. Figure 3-9 illustrates a situation in which a network control 
program (NCP) fails in a channel- attached controller that is also link attached 
to other controllers. If the controller in which the failure occurred is reloaded 
over a link, it becomes in effect a remote controller. Although the controller is 
again operational, and sessions with resources it controls can be reestablished, 
it cannot communicate with any remote communications controllers or with 
resources attached to those controllers. Nor can it communicate over data links 
with controllers (and their resources) in other domains. A significant portion 
of the network may thus be lost to use for as long as the reloaded controller 
operates as a remote controller. Extended NCP interconnection removes these 
limitations by providing the same functional capabilities for both 
channel-loaded and link-loaded network control programs. (Refer to Figure 
3-9.) 

Extended NCP ownership allows multiple SSCPs to concurrently share 
ownership of NCPs and SDLC links, regardless of where the NCPs and links 
are located in the network. (See "Extended Network- Control-Program 
Ownership" and "Configuration Flexibility" earlier in this chapter.) A network 
designer can define his network so th at_ any SSCP in the network can take over _ 
a failed TSTCP, its links,and its attached resources. 
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Network control programs (ACF/NCP/VSs) 
Host processors 
SDLC data link 
Data Channel 



NCP a fails. 



wsdaws \{\- 
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Prior to Level 3 of ACF: 

NCPjms reloaded over link ab; NCP ajs now a remote (link-loaded) NCP. 
Link-loaded NCPs cannot communicate with other link-loaded NCPs. Therefore, NCP a_ 
cannot communicate with NCP c, NCP d, or any of their attached resources. 



Level 3 of ACF: 



Controller C1 is reloaded over link ab. The function provided by a link-loaded 

NCP is the same as that provided by a channel-loaded NCP. NCP a_ can communicate 

with NCP c, NCP d, and their attached resources. 



Figure 3-9. Improved Network Recovery with Extended NCP Interconnection 
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Improved shareability of resources, together with the availability of alternate 
routes between subareas, can improve the ability of an SSCP to take over 
control of a resource when the current owner (SSCP), or the path to that 
owner, has become inoperative. These capabilities, along with the SSCP restart 
and SSCP takeover functions described in topics that follow, can improve the 
availability of a network— that is, its ability to continue functioning despite 
temporary failures of certain of its elements. 

Alternate Routing when a Virtual Route Is Lost 

If a virtual route is lost because one or more of the physical elements in its 
supporting explicit route becomes inoperative, the access methods and network 
control programs notify all logical units participating in LU-LU sessions using 
the route, the primary logical units participating in pseudo LU-LU sessions 
with BSC/SS stations, and all SSCPs involved in the SSCP-SSCP, SSCP-PU, 
and SSCP-LU sessions, that the sessions have been terminated. The SSCPs 
and logical units can then reinitiate the sessions, assuming that the 
corresponding end users wish to continue communicating and that an alternate 
virtual route is available. 

An SNA session may be reestablished over an available alternate route in the 
same class of service, or a different class of service may be specified. If no 
other virtual route is available in the same or different class of service, the 
session cannot be reestablished. A route must become available in order for 
the session to be reestablished. 

Because failure of an explicit route is disruptive to data flow, the logical units 
participating in each disrupted session must perform resynchronization 
processing to determine whether data was lost and react accordingly. 

One kind of failure does not cause sessions to be disrupted. Because of the way 
data is queued for a transmission group, the failure (or deactivation) of a link 
in a multiple-link transmission group causes the data for all sessions using the 
link to be sent instead over a different link in the same group. Therefore, 
unless the failing link was the only link in the group, no sessions are interrupted 
and no data is lost. 

Level 3 of ACF provides the same alternate routing capabilities for non-SNA 
stations as it does for SNA stations, with the following difference. In 
ACF/TCAM, non-SNA stations may be specified as eligible or ineligible to 
participate in cross-domain sessions. A station specified as eligible is subject to 
the same class-of-service selection as is an LU-LU session. On the other hand, 
class-of-service selection is not available for a station specified as ineligible to 
participate in cross-domain sessions. The virtual route assigned to sessions 
with ineligible stations is the same virtual route used for SSCP-PU sessions 
between the SSCP and the network control program that controls the stations. 

Nondisruptive SSCP Restart 

In prior levels of ACF, any reestablishment of an SSCP-PU or SSCP-LU 
session following failure of a network element in the route used by such 
sessions causes any active cross-domain LU-LU sessions involving 
corresponding LUs to be disrupted. With Level 3 of ACF, these LU-LU 
sessions are not interrupted by restarting the SSCP-PU or SSCP-LU sessions, 
provided that the associated physical units are capable of being reactivated 
without themselves resetting their logical units. Nondisruptive restart is 
available only for SNA stations supporting the function on nonswitched links; 
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available only for SNA stations supporting the function on nonswitched links; 
this function does not apply to SNA stations on switched links nor to any 
non-SNA stations. 



SSCP Takeover 



In networks controlled by Level 3 of ACF, a backup SSCP designated by the 
user can take over certain resources of a failed SSCP without disrupting any 
current LU-LU sessions involving those resources. (The physical units 
associated with the LUs must be capable of being reactivated without 
themselves resetting their logical units, as stated in the previous topic, 
"Nondisruptive SSCP Restart") Prior levels of ACF also permit a backup SSCP 
to acquire resources, but in every case the LU-LU sessions for acquired LUs 
are disrupted. 

Whenever the SSCP-PU session for the network control program is interrupted, 
the network control program informs all remaining SSCPs that own it (that is, 
have issued Activate commands for it) of the loss of the SSCP. The SSCPs, in 
turn, notify their respective network operators by operator-awareness 
messages. The operators can then perform the appropriate, 
installation-defined takeover procedures. At a convenient time, after the 
original SSCP is active again, the operators can cause the backup SSCP to 
relinquish the resources it acquired. The procedure is: 

1 . Terminate the LU-LU sessions for the resources acquired by the backup 
SSCP. 

2. Relinquish the backup SSCP's ownership of those resources. 

3. Reestablish the original SSCP's ownership of the resources. 

Reducing Cross-Domain Resource Definitions 

ACF/TCAM, Version 2, Release 3, simplifies the task of specifying a network 
by removing the requirement of defining every cross-domain resource to each 
domain that is to receive session-initiation requests from such resources. 

Cross-domain resources need only be defined in the domain that initiates the 
requests. Besides simplifying the task of specifying a network, this capability 
facilitates changing the network configuration. After a station is added to a 
network via the dynamic reconfiguration facility, it can request a session with a 
host LU in any domain. Defining the added station or its logical units to the 
domain beforehand is not necessary, provided that ACF/TCAM 
session-authorization processing in the domain will accept the session-initiation 
request. 
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Chapter 4. Migration and Planning Considerations 

ACF/TCAM, Version 2, uses the OS/VS1 or the OS/VS2 (MVS) operating 
system. ACF/TCAM can be used with any of the host processors that use 
these operating systems and have the conditional swapping feature. This 
chapter has information on migrating from earlier versions of TCAM, the 
releases of ACF/NCP/VS required for ACF/TCAM, Version 2, functions, 
and device charts. 

Migrating From TCAM 10 or ACF/TCAM, Version 1, to ACF/TCAM, Version 2 

TCAM 10 will operate with the following network control programs: 

. NCP/VS, Version 5 

. ACF/NCP/VS, Release 1 

• ACF/NCP/VS, Release 2 (with appropriate TCAM 10 PTFs) 

ACF/TCAM, Version 1, will operate with the following network control 
programs: 

• NCP/VS, Version 5 

• ACF/NCP/VS, Release 1 

• ACF/NCP/VS, Release 2 (with appropriate ACF/TCAM, Version 1, 
PTFs) 

• ACF/NCP/VS, Release 3 (with appropriate ACF/TCAM, Version 1, 
PTFs) 

ACF/TCAM, Version 2, Releases 1, 2, and 3, will operate with the following 
network control programs: 

• NCP/VS, Version 5 

• ACF/NCP/VS, Release 1 (with appropriate ACF/NCP/VS PTFs) 
. ACF/NCP/VS, Release 2 (with appropriate ACF/NCP/VS PTFs) 
. ACF/NCP/VS, Release 3 

Functions supported by TCAM 10 or ACF/TCAM, Version 1 (with the 
appropriate network control program), are also applicable for ACF/TCAM, 
Version 2, with the following exceptions: 

• A host node cannot be used as a transient node (intermediate network node) 

• OS/VS2 SVS does not operate with ACF/TCAM, Version 2 

Network Control Programs Required for Specific New ACF/TCAM, Version 2, 
Functions 

The following ACF/TCAM, Release 1, functions can be used with NCP/VS, 
Version 5, and ACF/NCP/VS, Releases 1, 2, and 3: 

• Enhanced dynamic display of NCP storage (with appropriate NCP/VS, 
Version 5 PTF) 

• Station-operator-initiated SDLC link test (with appropriate NCP/VS, 
Version 5, PTF) 

• ACF/TCAM's use of the Programmed Cryptographic Facility program 
product 

The following ACF/TCAM, Release 1, functions can be used with 
ACF/NCP/VS Release 1, 2, or 3: 
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• Multisystem Networking Facility support of channel-attached 3790 Systems 
and 3274 Control Units 

• ACF/TCAM's use of the Network Communications Control Facility 
program product 

The following ACF/TCAM, Release 1, functions can be used with 
ACF/NCP/VS, Releases 2 and 3: 

• Negotiable session-initiation parameters for secondary LUs 

• Network-operator-initiated SDLC link test 

• Intensive mode recording of SDLC data link errors 

• Dynamic reconfiguration of SNA devices 

• ACF/TCAM's use of 3705-11 Communications Controller, Models J, K, and 
L 

For ACF/TCAM, Release 2, the subsystem interface function can be used 
with: NCP/VS, Version 5, and ACF/NCP/VS, Releases 1, 2, or 3. 

With the exception of dynamic NCP dump support and reduced cross-domain 
definitions, the new capabilities of ACF/TCAM, Version 2, Release 3, are 
supported only in conjunction with ACF/NCP/VS, Release 3. The dynamic 
NCP dump capability can be used with NCP/VS, Version 5, and all releases of 
ACF/NCP/VS. Reduction of definition requirements for cross-domain 
resources is available with all releases of ACF/NCP/VS. 

Multiple-Domain Considerations 

The following ACF/TCAM, Version 2, enhancements are effective (1) 
between two hosts containing ACF/TCAM, Version 2, and (2) between a host 
containing ACF/TCAM, Version 2, and a host containing ACF/VTAM, 
Release 2: 

• Negotiable session-initiation parameters 

• Channel-attached 3274 Control Unit and 3790 Communication System 

• ACF/TCAM's use of the Network Communications Control Facility 
program product 1 

ACF/TCAM, Version 2, can use the Programmed Cryptographic Facility 
program product only when communicating with a host containing 
ACF/TCAM, Version 2, or any release of ACF/VTAM. 

The following enhancement is effective only from a host containing 
ACF/TCAM, Version 2, when communicating with a host containing 
ACF/TCAM, Version 1 or 2, or containing ACF/VTAM, Release 1 : 
channel-attached 3274 and 3790 networking 

A host with ACF/TCAM, Version 2, Release 3 can coexist in a 
multiple-domain network with hosts containing any of the access methods 
listed below. 

. ACF/TCAM, Version 1 

• ACF/TCAM, Version 2, Releases 1 and 2 

• ACF/VTAM, Releases 1, 2, and 3 



1 Also effective between (1) ACF/TCAM, Version 2, and ACF/TCAM, Version 1, hosts and 
(2) between ACF/TCAM, Version 2, and ACF/VTAM, Release 1, hosts. 
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In such cases, however, the function available with ACF/TCAM, Release 3, 
will be determined by the capabilities of the access method with which it 
communicates, and is generally that of the earliest level access method. 



Devices That Can Be Used with ACF/TCAM Version 2 



Host Processors 



ACF/TCAM, Version 2, can operate in any of the host processors used for 
OS/VS1 and OS/VS2 MVS; ACF/TCAM requires that the processor be 
capable of executing Compare and Swap instructions. 



Direct-Access Storage Devices 



Communications Controllers 



Transmission Control Units 



SNA Cluster Controllers 



For disk message queues: 

• 2314 Storage Control 

• 3330 Disk Storage Models 1 and 2 

• 3340 Disk Storage and Control 

• 3350 Direct Access Storage 

For checkpoint data sets, all of the devices listed for disk message queues can 
be used; rotational position sensing (RPS) is not used. 

For COM WRITE data sets, all devices supported by the Basic Sequential 
Access Method (BSAM) can be used. 



IBM 3705-1 Communications Controller 
IBM 3705-11 Communications Controller 



IBM 2701 Data Adapter Unit 
IBM 2702 Transmission Control 
IBM 2703 Transmission Control 



IBM 3274 Control Unit 

IBM 3276 Control Unit Display Station 

IBM 3601 Finance Communication Controller 

IBM 3631 Plant Communication Controller 

IBM 3632 Plant Communication Controller 

IBM 3791 Controller 

IBM 8130 Processor 

IBM 8140 Processor 



Communication System Devices 



All of the communication devices that can be used with ACF/TCAM, Version 
2, are listed in Figure 4-1; the figure also lists the devices that can use the 
subsystem interface in ACF/TCAM, Release 2. Figure 4-2 lists the devices 
that can use the teleprocessing online test executive (TOTE). 
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1030 Data Collection System 
1050 Data Communication System 
1060 Data Communication System 
2260 Display Station 
2265 Display Station 

2740 Communication Terminal 

2741 Communication Terminal 
2760 Optical Image Unit 

AT&T 83B3 or WU 115A (Line Control Type) 

CPT-TWX (M33/35) 

WT Teletype (CC1TT 2 and 5) 
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BSC Stations 



1130 Computing System 

1826 Data Adapter Unit 

2715 Transmission Control 

2770 Data Communication System 

2780 Data Transmission Terminal 

2972 General Banking Terminal System 

3270 Information Display System 

3670 Brokerage Communication System 

3735 Programmable Buffered Terminal 

3740 Data Entry System 

51 1 Portable Computer 

System/3 

System/360, Model 20 

System/360 

System/370 
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SDLC Stations 



3270 Information Display System 

3600 Finance Communication System 

3614 Consumer Transaction Facility 

3624 Consumer Transaction Facility 

3650 Programmable Store System, Models A25, 

B25, A75, B75, C75, and D75 
3767 Communication Terminal 
3770 Data Communication System 
3790 Communication System 
6670 Information Distributor 

Rorioc/1 



Note 3 
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Note 2 
Note 2 
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Note 6 



Note 3 

Note 2 
Note 2 

Note 4 



Notes: 

1. On switched lines only. 

2. On nonswitched lines only. 

3. 3276-11, -12, -13, -14 on both switched and nonswitched lines; 3271-11, -12, 3274-1 C, and 3275-11, -12 on nonswitched lines only. 

4. Configurations 9165 and 9169 only. 

5. Supported as 2740-1 on both switched and nonswitched lines; supported as 2740-2 on nonswitched lines only. 

6. TSO support applies only to 3790 with 3270 data stream compatibility. 

Figure 4-1. Communication Devices and Stations Supported by ACF/TCAM, Version 2 (Part 1 of 3) 
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Stations Supported as Compatible SS Stations 




3767 Communication Terminal (as 2740) 
3767 Communication Terminal (as 2741 
5100 Portable Computer (as 2741) 
5110 Portable Computer (as 2741) 
Communicating Magnetic Card SELECTRIC 

Typewriter (as 2741 ) 
System/7 (as 2740) 
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Stations Supported as Compatible BSC Stations 



3274 Control Unit, Model 1C (as 3271) 
3276 Control Unit Display Station, 

Models 1, 2, 3, and 4 (as 3271) 
3770 Data Communication System (as 2770) 
3780 Data Transaction Terminal (as 2770) 
5275 Direct Numerical Control Station 

(as 3275) 
6670 Information Distributor (as 2770) 
8100 Processor (as 3270) 
Series/1 (as System/3) 
System/7 (as System/3) 
System/32 (as System/3) 
System/34 (as System/3) 
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Stations Supported as Compatible SDLC Stations 



3270 Information Display Station 










(as 3790) 
3631 Plant Communication Controller 


— 


V 


V 


V 


(as 3601 ) 
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3632 Plant Communication Controller 








(as 3602) 
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3770 Data Comunication System (as 3767) 
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5937 Industrial Terminal 
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8130 Processor (as 3791) 
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8140 Processor (as 3791) 


— 


System/32 (as 3770) 


— 


System/34 (as 3767, 3770, 3791 ) 


— 


System/38 (as 3770) 


— 



Notes: 

1. On switched lines only. 

2. On nonswitched lines only. 

3. 3276-11, -12, -13, -14 on both switched and nonswitched lines; 3271-11, -12, 3274-1C, and 3275-11, -12 on nonswitched lines only. 

4. Configurations 9165 and 9169 only. 

5. Supported as 2740-1 on both switched and nonswitched lines; supported as 2740-2 on nonswitched lines only. 

6. TSO support applies only to 3790 with 3270 data stream compatibility. 

Figure 4-1. Communication Devices and Systems Supported by ACF/TCAM, Version 2 (Part 2 of 3) 
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Stations Supported via Local Attachment 





2260 Display Station 


V, 


V 


_ 


2715 Transmission Control Unit 


V 




— 


3270 Information Display System 


V 


V 


V 


(3272-1, -2; 3274-1 A, -1B, -1D) 








3790 Communication System, Configurations 9165 








and 9169 only 


y/ t 


Note 6 


V 


7770 Audio Response Unit 


V 


— 





Notes: 

1. On switched lines only. 

2. On nonswitched lines only. 

3. 3276-11, -12, -13, -14 on both switched and nonswitched lines; 3271-11, -12, 3274-1 C, and 3275-11, -12 on nonswitched lines only. 

4. Configurations 9165 and 9169 only. 

5. Supported as 2740-1 on both switched and nonswitched lines; supported as 2740-2 on nonswitched lines only. 

6. TSO supported applies only to 3790 with 3270 data stream compatibility. 

Figure 4-1. Communication Devices and Stations Supported by ACF/TCAM, Version 2 (Part 3 of 3) 
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IBM 



1030 Data Collection System 
1050 Data Communication System 
1060 Data Communication System 
1130 Computing System (station) 
2260 Display Station with 
2848 Display Control (local and remote) 
2265 Display Station with 
2845 Display Control 

2740 Communication Terminal (Models 1 and 2) 

2741 Communication Terminal 
2760 Optical Image Unit 

2770 Data Communication System 

2780 Data Transmission Terminal 

2790 Data Communication System 

3270 Information Display System (Models 11 and 12) 

3275 Display Station 

3277 Display Station 

3284 Printer 

3286 Printer 

3670 Brokerage Communication System 

3767 Communication Terminal (Models 1 and 2) 

3770 Communication Terminal (Models 1 and 2) 

3780 Data Communication Terminal 

System 360/Model 20 (station) 

System/360, Models 25 and above (station) 

System/370, Models 125 and above 



*Supported by TOTE on 2701, 2702, and 2703 lines only. 



TOTE supports the following control units: 



Control Test 

Terminal Device 



Alternate 
Printers 



X 
X 
X 
X 

Note 2 
Notes 1 
and 2 
Note 1 
X 



IBM 2701 Data Adapter Unit 

IBM 2702 Transmission Control 

IBM 2703 Transmission Control 

IBM 2715 Transmission Control Unit 

IBM 3271 Control Unit, Models 1, 2 and 11, 12 

IBM 3272 Control Unit 

IBM 3705 Communications Controllers 
IBM 7770 Audio Response Unit Model 3 



In addition, if the test device is a symbolically named link off the 3705, TOTE will run a test 

to the link. These tests may test 3705 hardware, modems, autocall adapters, or exercise the SDLC 

link with the test command. 

Notes: 

1. In OS/VS1 only. 

2. Tested by certain test when run against the appropriate 3275, 3277, 3284, and 3286. 

Figure 4-2. Devices That Can Be Used with TOTE 
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Glossary 



This glossary contains definitions reproduced from the 
American National Dictionary for Information Processing, 
copyright 1977 by the Computer and Business Equipment 
Manufacturers Association, copies of which may be 
purchased from the American National Standards Institute 
at 1430 Broadway, New York, New York 10018. 

ANSI definitions are identified by an asterisk. The symbol 
(ISO) at the beginning of a definition indicates that the 
definition has been approved for inclusion in the Data 
Processing Vocabulary of the International Organization for 
Standardization. The symbol (SCI) indicates that the 
definition is from an early working paper of ISO Technical 
Committee 97/Subcommittee 1 and that agreement has not 
yet been reached among its members. 

ACF: Advanced Communications Function. 

Advanced Communications Function (ACF): A group 
of three IBM program products (ACF/TCAM, ACF/VTAM, 

ACF/NCP/VS) that use the concepts of SNA and the 
capabilities of such products as the IBM 3705 
Communications Controllers, SNA cluster controllers, and 
terminals to support online applications in large or small 
networks. The Multisystem Networking Facility of 
ACF/TCAM, ACF/VTAM, and ACF/NCP/VS allows the 
interconnection of two or more domains into one 
consolidated and coordinated multiple-domain network. See 
also Multisystem Networking Facility. 

Advanced Communications Function for the 
Telecommunications Access Method (ACF/TCAM): 

The method used to transfer data between main storage and 
remote or local stations. ACF/TCAM application programs 
use either GET and PUT or READ, WRITE, and CHECK 
macro instructions to request the transfer of data, which is 
performed by message handlers. The message handlers 
synchronize the transfer, thus eliminating delays for station 
input/output operations. The Multisystem Networking 
Facility is an optional feature of ACF/TCAM that allows a 
multiple-domain network to be created. 

alternate extended route: An extended route between a 
pair of host nodes, used to route messages in a particular 
transmission category when the primary extended route for 
that transmission category is unavailable due to the failure 
of a component. See also extended route, primary extended 
route, route. 

AMH: Application message handler. 

API: Application program interface. See also GET/PUT 
interface and subsystem interface. 

application message handler (AMH): A user-defined 
routine that processes messages that are received by the 
message control program (MCP) from an application 
program or that are sent by the MCP to an application 
program. See also message handler. Contrast with device 
message handler. 



application program: A program written for or by a user 
that applies to the user's work. In ACF/TCAM, a program 
that uses the GET/PUT interface. 

asynchronous: Without regular time relationship; 
unexpected or unpredictable with respect to the execution of 
a program's instructions. 

automatic purge/copy /redirect: A collection of 

message-handler and extended operator control functions 
that permit messages to be conditionally or unconditionally 
redirected to another destination, copied to another 
destination, or purged (that is, not sent to any destination). 

basic networking: Functions available with the 
Multisystem Networking Facility that are basic to all 
SNA-based networks. Contrast with extended networking. 

basic operator command: An operator command directed 
to the basic operator control system service program (SSP). 

basic operator control SSP: A system service program 
that processes a set of basic operator commands that allow 
the operator to determine the status of the network and to 
alter, activate, and deactivate portions of that network by 
entering appropriate commands from the system console, a 
remote station, or an application. The basic operator 
control SSP is required in order to execute an ACF/TCAM, 
Version 2, message control program. 

binary synchronous communication (BSC): 

Communication using binary synchronous line discipline. 
See binary synchronous transmission. 

binary synchronous transmission: Data transmission in 
which synchronization of characters is controlled by time 
signals generated at the sending and receiving stations. 
Contrast with start-stop transmission and synchronous data 
link control. 

bind image: In SNA, a string of parameters specifying 
allowable protocols for LU-LU sessions. 

broadcast: The simultaneous transmission of data to a 
number of stations. 

BSC: Binary synchronous communication. 

BSC or SS station: A station on a BSC or start-stop line. 

buffer: (1) *A routine or storage used to compensate for a 
difference in rate of flow of data, or time of occurrence of 
events, when transferring data from one device to another. 
(2) An area of storage that is temporarily reserved for use in 
performing an input/output operation, into which data is 
read or from which data is written. 

channel: See data channel. 

channel-attached: A station or communications 
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controller that is connected directly to a host processor's 
data channel by a local cable. Contrast with link-attached. 

checkpoint: To periodically record information about 
ACF/TCAM's environment; this information is used to 
re-create that environment when ACF/TCAM is restarted 
following closedown or a system failure. 

checkpoint data set: An optional ACF/TCAM data set 
that contains the checkpoint records used to reconstruct the 
message control program's environment after closedown or 
system failure when the ACF/TCAM checkpoint/restart 
facility is utilized. 

checkpoint records: Records that contain the status of a 
job and the system at the time the records are written by the 
checkpoint routine. These records provide the information 
necessary for restarting a job without having to return to the 
beginning of the job. 

checkpoint/restart facility: A facility that records the 
status of the network at designated intervals or following 
certain events. After system failure, the system can be 
restarted and continue without loss of messages. 

class of service: A list of several virtual routes to which an 
LU-LU session may be assigned. See also virtual route. 

closedown: The orderly deactivation of the message 
control program. 

cluster controller: A device that can control the 
input/output operations of more than one device. See also 
communication controller. 

CMC: Communications management configuration. 

cold restart: Startup of a message control program (MCP) 
following either closedown or system failure. A cold restart 
ignores the previous environment (that is, the MCP is 
started as if this were the initial startup). It is the only type 
of restart possible when no checkpoint/restart facility is 
used. Contrast with warm restart. 

communication control unit: Either a communications 
controller or a transmission control unit (TCU). 

communications controller: A type of communication 
control unit whose operations are controlled by a program 
stored and executed in the unit. It manages the details of 
line control and routing of data through a network. It can 
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from a cluster controller or station. As used in this 
publication, the term applies exclusively to the IBM 3705 
Communications Controller. Contrast with transmission 
control unit. See also cluster controller. 

communication management configuration (CMC): A 

configuration available with Level 3 of ACF in which a 
single SSCP owns and controls all of the resources in a 
network. 

communication management processor: In a 



communication management configuration, the host 
processor that owns and controls all resources in the 
network. Contrast with data host. 

COM WRITE: A sequential data set in which trace 
information is written. 



cross-domain: 

domains. 



Pertaining to data communication between 



cross-domain communication: Synonym for networking. 

cross-domain LU: A logical unit (LU) located in another 
domain. 

cryptographic: Pertaining to the transformation of data to 
conceal its meaning. 

data channel: A device that connects a processor with the 
I/O control units. Synonymous with I/O channel. 

data host: In a communication management configuration, 
a host processor that owns no network resources, including 
its channel-loaded network control programs. Contrast with 
communication management processor. 

data link: See link. 

data Staging: An extended networking technique in which 
high-volume, low-priority message traffic is moved from one 
host node to another, progressively approaching the 
destination host. Data staging allows such traffic to be 
moved at a convenient time to avoid overloading 
cross-domain links and to protect response times for 
high-priority cross-domain inquiries. 

decipher: The process of converting enciphered data into 
clear data. Synonymous with decrypt. Contrast with 
encipher. 

decrypt: Synonym for decipher. 

destination: The place to which a message being handled 
by an ACF/TCAM message handler is to be sent. 

device message handler (DMH): A user-defined routine 
that processes messages being received by the message 
control program (MCP) from a station or being sent by the 
MCP to a station. See also message handler. Contrast with 
application message handler. 

direct access storage device (DASD): A device in 
which the access time is effectively independent of the 
location of the data. 

distributed function: The use of programmable stations 
and controllers to perform operations that are otherwise 
done by the host processor, such as network control, 
processing, and error-recovery operations. 

DMH: Device message handler. 
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domain: The collection of network resources controlled by 
one SSCP located. See also multiple-domain network, 
single-domain network. 

dynamic accounting facility: An ACF/TCAM service 
facility that gathers resource utilization data for processing 
by user-supplied applications. 

emulation mode: The function of a network control 
program (NCP/VS or ACF/NCP/VS) that enables it to 
emulate a transmission control unit. Contrast with network 
control mode. 

emulation program (EP): A control program that allows 
a channel-attached 3705 Communications Controller to 
emulate the function of an IBM 2701 Data Adapter Unit, 
IBM 2702 Transmission Control, or an IBM 2703 
Transmission Control. Contrast with network control 
program. 

encipher: The process of converting clear data into 
enciphered data. Synonymous with encrypt. Contrast with 
decipher. 

enciphered data: Data that is intended to be illegible to all 
except those who legitimately possess the means to 
reproduce the clear data. 

end user: The ultimate source or destination of 
information flowing through the network. It may be an 
application program, an operator, or a data medium (such as 
cards or tapes). 

end USer-SSCP echo test: A diagnostic aid that permits 
an SNA station operator to ensure that the path to the 
owning host is functional. 

EP: Emulation program. 

error record: Five bytes assigned to each message 
processed by a message handler. These bytes indicate 
physical or logical errors that have occurred during 
transmission or during subsequent processing or queuing of 
the message; they are checked by error-handling macros in 
the inmessage and outmessage subgroups of a message 
handler. Synonymous with message error record. 

error-recovery procedures: A set of internal 
ACF/TCAM routines that attempt to recover from 
transmission errors. 

EU-SSCP echo test: See end user-SSCP echo test. 

explicit route: A sequence of physical network elements 
(such as links and communications controllers) over which 
two subareas communicate. See also subarea. Contrast with 
virtual route. 

extended NCP interconnection: The capability 
available with ACF/NCP/VS, Release 3, that allows the 
same functions to be performed by both channel-loaded and 
link-loaded network control programs (ACF/NCP/VSs, 
Release 3). With this capability, any communications 



controller can be connected to to any other communications 
controller in the network. 

extended NCP ownership: A capability available with 
Level 3 of ACF that allows the link between two network 
control programs to be owned by a maximum of eight 
SSCPs. 

extended network: A multiple-domain network that is 
controlled by the ACF/TCAM extended networking 
capability. 

extended networking: A collection of ACF/TCAM 
macros, system service programs, and message-handler 
facilities that facilitate network definition, network 
management, and error recovery in a multiple-domain 
network. 

extended operator command: An operator command 
directed to the extended operator control system service 
program (SSP). 

extended operator control SSP: A system service 
program that supports a set of extended operator commands 
that are not required in order to control an ACF/TCAM 
network, but that are useful in some data communication 
environments. The extended operator control SSP is 
required if one or more of the following ACF/TCAM 
functions is used by the MCP: 

• The extended networking capability 

• The online retrieval SSP 

• The automatic purge/copy/redirect capability 



extended route: In an extended network, a series of one 
or more SNA routes connecting one host node to another 
host node. See also alternate extended route and primary 
extended route. 

GET/PUT interface: The means by which user-written 
ACF/TCAM application programs communicate with the 
message control program using either GET/PUT macros or 
READ/WRITE/CHECK macros. Use of one of these sets of 
macros is implied when this term is used. Contrast with 
subsystem interface. 

host LU: An SNA logical unit (LU) in a host processor; an 
ACF/TCAM host LU consists of a DMH, an LU services 
component, and MCP code. Contrast with outboard LU. 

host node: In SNA, a node that contains a host processor. 
An example is a System/370 computer with OS/VS2 and 
ACF/TCAM. 

host processor: The controlling processor with its 
operating system, access method, and application programs. 
A system services control point (SSCP) may be located in the 
host processor. 

incoming message: A message transmitted from a station 
to the host processor. 
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initiator: The component of ACF/TCAM that is executed 
as the job-step task. The initiator starts, monitors, and 
restarts the message control program, ACF/TCAM system 
service programs, and user-supplied system service 
programs. It also provides abend dump facilities and is 
capable of displaying status information at the system 
console. 

inquiry /reply: An ACF/TCAM application in which a 
device message handler receives a message from a station 
and then routes it to an application program that processes 
the data in the message and generates a reply; the reply is 
routed by the device message handler to the inquiring 
station. 

internodal awareness SSP: In an extended network, a 
system service program in a host node that communicates 
with internodal awareness SSPs in other host nodes to: 

1. Monitor the status of other host nodes in the network 
and inform other host nodes of the presence of its own 
host node. 

2. Monitor the status of applications located in other 
domains of the network and inform other host nodes 
of the status of applications located in its own host. 

internodal sequence number synchronization SSP: A 

system service program that operates in an extended 
network. It (1) requests retransmission from any 
cross-domain host node of sequence-numbered messages not 
received on a utility session and (2) retransmits 
sequence-numbered messages flowing on a utility session 
when requested to do so by another host node or an extended 
operator command. Internodal sequence number 
synchronization SSPs in all host nodes in the extended 
network cooperate with each other to perform these 
functions. 

I/O channel: Synonym for data channel. 

Level 3 of ACF: ACF/TCAM, Version 2, Release 3; 

ACF/VTAM, Release 3; and ACF/NCP/VS, Release 3. 

line: (1) Any physical medium, such as a wire or telephone 
circuit, that connects one or more stations to a 
communication control unit. (2) Loosely, a data link; see 
link. 

link: (1) In SNA, the physical connections and the 
connection protocols between network control programs and 
between network control programs , and cluster controllers 



link-attached: A station or communications controller 
that is connected to a channel-attached communications 
controller by means of a data link. Contrast with 
channel-attached. 

link test level 2: A diagnostic aid that provides the 
capability to test a single SNA station on a nonswitched link 
while other stations on the link remain available to the host. 

load balancing: An extended networking technique for 



balancing the message flow between any pair of host nodes 
by assigning different paths to different messages flowing 
between the nodes. 

local: See channel-attached. 

local station: A station whose control unit is connected 
directly to a computer data channel by a local cable. Also 
referred to as a channel-attached station. Contrast with 
remote station. 

log data set: A data set consisting of the messages or 
message segments recorded on a secondary-storage medium 
by the ACF/TCAM logging facility. 

logical unit (LU): The means by which an end user 
accesses the network in order to communicate with another 
end user. It is also the means by which an end user accesses 
the services provided by the system services control point 
(SSCP). See also host LU, outboard LU, physical unit, 
system services control point. 

logging service facility: An ACF/TCAM service facility 
that selectively causes messages or message segments to be 
copied onto a sequential storage medium. The log produced 
by the logging service facility provides a record of message 
traffic through the MCP. 

LU: Logical unit. 

LU-LU session: In SNA, a session between two logical 
units in the network. It provides communication between 
two end users, each associated with one of the logical units. 

MCP: Message control program. 

message: A combination of characters and symbols 
transmitted from one point to another in a network. 

message control program (MCP): A generic term 
referring to any specific implementation of an ACF/TCAM 
access method, including I/O routines, buffering routines, 
activation and deactivation routines, service facilities, and 
SNA support. 

message error record: Synonym for error record. 

message handler (MH): A sequence of user-specified 
macro instructions that invoke routines that examine and 
process control information in message headers and perform 
functions necessary to prepare messages for forwarding to 
their destinations. 

message priority: The order in which messages in a 
destination queue are transmitted to a destination, relative 
to each other. Higher-priority messages are forwarded 
before lower-priority messages. See also transmission priority. 

message queue data set: An ACF/TCAM data set that 
contains one or more destination queues. 

message routing: A major MCP function, which involves 
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determining the correct destination for each message 
entered from a station, LU, or application and placing each 
message on the appropriate destination queue. 



access to data in an option field. User-written 
message-handler exit routines also have access to data in an 
option field. 



MH: Message handler. 

MSNF: Multisystem Networking Facility 



outboard LU: An SNA logical unit (LU) located outside a 
host processor in an SNA cluster controller node or a 
terminal node. Contrast with host LU. 



multiple-domain network: A network with more than 
one system services control point (SSCP). Contrast with 
single-domain network. 

multiple routing: A capability available with Level 3 of 
ACF that allows up to eight physical routes between a pair of 
subareas. 

Multisystem Networking Facility (MSNF): An 
optional feature of ACF/TCAM and ACF/VTAM that 
permits these access methods, together with ACF/NCP/VS, 
to control a multiple-domain network. 

NCP: Network control program; this generic term is used 
in this publication when referring to NCP/VS, Version 5, 
and ACF/NCP/VS, Releases 1, 2, and 3. 

network: In data processing, a user-application network. 

network control program: A control program for the 
IBM 3705 Communications Controller generated by the user 
from a library of IBM-supplied modules. As used in this 
publication, network control program refers to the IBM 
programs NCP/VS, Version 5, and ACF/NCP/VS, Releases 
1, 2, and 3. Contrast with emulation program. 

networking: In a multiple-domain network, 
communication between domains. Synonymous with 
cross-domain communication. 

node: In SNA, an addressable point in a network. 

nonswitched line: A connection between a remote station 
and a host processor that does not have to be established by 
dialing. Contrast with switched line. 

online retrieval SSP: A system service program that 
allows operators at designated stations or logical units (LUs) 
to retrieve disk-queued messages based upon origin or 
destination, time of entry, or input or output sequence 
number. 



pacing: In SNA, a technique by which a receiving LU 
controls the rate of transmission of a sending LU to prevent 
overrun. See also route pacing. 

parallel links: Two or more SDLC links between two 
network control programs (ACF/NCP/VS, Release 3). 

primary logical unit (PLU): A logical unit that issues a 
Bind Session request to establish an LU-LU session;epilO. 
the logical unit that controls an LU-LU session. Contrast 
with secondary logical unit. See also logical unit. 

public network: A network established and operated by 
communication common carriers or telecommunications 
Administrations for the specific purpose of providing 
circuit-switched, packet-switched, and leased-circuit services 
to the public. Contrast with user application network. 

queue: (1) A line or list formed by items in a system waiting 
for service; for example, tasks to be performed or messages 
to be transmitted in a message-routing system. (2) To 
arrange in, or form, a queue. See also queuing. 

queuing: The programming technique used to handle 
transactions arriving at an unpredictable rate. See also 
queue. 

remote: See link-attached. 

remote Station: A station that is connected to a computer 
data channel through either a communication control unit or 
an audio response unit. Also referred to as a link-attached 
station. Contrast with local station. 

route: In an SNA network, a series of interconnected 
SDLC links and SNA nodes over which messages flow from 
one subarea to another subarea. 

route pacing: The monitoring and flow-control mechanism 
that ACF/TCAM uses to alleviate congestion on virtual 
routes. See also pacing. 



operator command: A command entered at an operator 
control station, the system console, or from an application 
program to examine or alter the status of the network during 
execution. 

operator control: See basic operator control SSP and 
extended operator control SSP. 

option field: A storage area containing data relating to a 
particular station, component, line, or application program. 
Certain message-handler routines that need origin- or 
destination-related data to perform their functions have 



route verification: A capability available with 
ACF/TCAM, Version 2, Release 3, which allows the 
network operator to verify that any or all explicit routes 
between the ACF/TCAM subarea and any other subarea are 
active and usable. 

save/restore message queues SSP: A system service 
program that saves unsent messages on tape and restores 
them to an altered message control program (MCP) 
following a cold restart. This program also facilitates 
recovery when the message queue data set on nonreusable 
disk becomes full and may be used to obtain an online dump 
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of unsent messages from one or more destination queues on 
disk. 

SDLC: Synchronous data link control. 

secondary logical unit (SLU): In an SNA LU-LU 
session, the partner that receives the Bind Session request. 

service facility: An auxiliary routine designed to support 
the message control program (MCP). It runs under the 
control of the MCP itself and is invoked by the MCP on an 
as-needed basis. Contrast with system service program and 
utility. 

session: See SNA session. 

Session outage notification: A procedure available with 
ACF/TCAM, Version 2, Release 3, which notifies the ends 
of an SNA session when a virtual route is interrupted. 

single-domain network: A network with one system 
services control point (SSCP). Contrast with 
multiple-domain network. 

SLU: Secondary logical unit. 

SMQ: See save/restore message queues SSP. 

SNA: Systems Network Architecture. 

SNA session: A logical connection between two network 
addressable units (NAUs) to allow them to communicate. 
SNA sessions can exist between SSCPs (SSCP-SSCP 
session), between an SSCP and a physical unit (SSCP-PU 
session), between an SSCP and a logical unit (SSCP-LU 
session), and between logical units (LU-LU session). 

SS: Start-stop transmission. 

SSCP: System services control point. 

SSCP backup: An ACF/TCAM facility allowing an SSCP 
located in one domain to assume ownership of resources 
located in an adjacent domain, either as a result of host-node 
failure in the adjacent domain or as a means of processor 
load-balancing. 

SSCP-LU session: An SNA session between the system 
services control point (SSCP) and a logical unit (LU). It is 
used to support logical-unit-related control and use of the 
communication system. Each logical unit in the network 
must participate in session with the SSCP that provides 
services for that logical unit. 

SSCP-PU session: An SNA session between the system 
services control point (SSCP) and a physical unit (PU) that 
is used to control the physical configuration of a network 
and to control an individual node. 

SSP: See system service program. 

startup/restart message generation facility: An 



ACF/TCAM service facility that generates and sends 
tailored messages to stations and outboard LUs when the 
message control program (MCP) is started or restarted. 

Start-Stop (SS) transmission: Asynchronous 
transmission in which a group of bits is preceded by a start 
bit that prepares the receiving mechanism for the reception 
and registration of a character and is followed by at least one 
stop bit that enables the receiving mechanism to come to an 
idle condition pending the reception of the next character. 
Contrast with binary synchronous transmission, synchronous 
data link control. 

station: (1) A point in a network at which data can enter or 
leave. (2) In SNA, one of the input or output points on an 
SDLC data link. (3) One or more computers, terminals, or 
devices at a particular location. See NCP station, non-NCP 
station, SNA station non-SNA station. 

subarea: In terms of ACF/TCAM, the collection of 
resources directly controled by a message control program or 
a network control program. 

subsystem interface: For ACF/TCAM, the subset of 
ACF/VTAM record-mode instructions that allows 
IBM-supplied subsystems to operate with ACF/TCAM, 
Version 2, Releases 2 and 3. Contrast with GET/PUT 
interface. 

switched line: A communication line in which the 
connection between the host processor and a remote station 
is established by dialing. Contrast with nonswitched line. 

synchronous data link control (SDLC): A discipline for 
managing synchronous, transparent, serial-by-bit 
information transfer over a communication channel. 
Transmission exchanges may be full-duplex or half -duplex 
over switched or nonswitched data links. The 
communication channel configuration may be 
point-to-point, multipoint, or loop. Contrast with binary 
synchronous transmission, start-stop transmission. 

system service program (SSP): IBM-supplied or 
user-supplied programs that perform system-oriented 
auxiliary functions in support of the message control 
program (MCP). System service programs run under the 
control of the initiator as attached subtasks. See also basic 
operator control SSP, extended operator control SSP, online 
retrieval SSP, save/restore message queues SSP, internodal 
awareness SSP, internodal sequence number synchronization 
SSP. 

system services control point (SSCP): In SNA, a 

network addressable unit that provides configuration, 
maintenance, and session services via a set of command 
processors — network services — supporting physical units and 
logical units. The SSCP must be in session with each logical 
unit and each physical unit for which it provides these 
services. 

Systems Network Architecture (SNA): The total 
description of the logical structure, formats, protocols, and 
operational sequences for transmitting information units 
through a communication system. 
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TCAM: Telecommunications access method. See 
Advanced Communications Function for the 
Telecommunications Access Method (ACF/TCAM). 



TSO: Time sharing option. An optional configuration of 
the operating system providing conversational time sharing 
from remote stations. 



teleprocessing online test executive (TOTE): A 

facility that permits either a system console operator or a 
remote control station user to test transmission control units 
and remote stations that are not attached through the NCP. 

terminal: Synonymous with station. 

terminal node: An SNA station that uses IBM-supplied 
code for line and device control and is not programmable, 
having less processing capability than a cluster controller 
node. Examples are the IBM 3270, 3767, and 3770 systems. 
See also host node, NCP node, cluster controller node. 

transmission category: A subset of the messages flowing 
over utility sessions in an extended network. 

transmission control unit (TCU): A communication 
control unit whose operations are controlled solely by 
programmed instructions from the host processor to which 
the unit is attached; no program is stored or executed in the 
unit. 

transmission group: (1) The logical connection between 
two network control programs (ACF/NCP/VS, Release 3). 
The group contains one or more active SDLC links. (2) The 
logical connection between the host processor and the 
network control program (ACF/NCP/VS, Release 3), even 
though this connection consists only of a single data channel. 



user application network: A configuration of data 
processing products, such as processors, controllers, and 
terminals, established and operated by users for the purpose 
of data processing or information exchange, which may use 
services offered by common carriers or telecommunication 
Administrations. Contrast with public network. 

utility: An auxiliary routine designed to support the 
message control program (MCP), which runs under the 
control of the operating system. Contrast with system 
service program, service facility. 

utility session: In an extended network, a session used to 
transmit message traffic between host nodes. One utility 
session is established between each pair of host nodes for 
each transmission category defined for the pair of host 
nodes. Data messages being routed from host to host flow 
on the utility session corresponding to their transmission 
category. 

virtual route: A logical connection between a pair of 
subareas that participates in session. Contrast with explicit 
route. 

warm restart: Restart of ACF/TCAM following either a 
quick or a flush closedown; the ACF/TCAM 
checkpoint/restart facility restores the ACF/TCAM 
environment as nearly as possible to its condition before 
closedown or failure. Contrast with cold restart. 
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